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ABSTRACT 

This  thesis  presents  a  database  application,  the  Republic  of  Korea  military 
personnel  management  system.  In  order  to  maximize  the  utilization  of  personnel 
resources  a  computerized  personnel  information  system  is  needed. 

An  important  consideration  in  database  design  is  to  assure  that  data  can  be  used 
for  a  wide  variety  of  applications  and  can  be  changed  quickly  and  independently.  For 
this  purpose,  we  discuss  normal  forms  including  functional  dependency  concepts. 

A  simple  data  base  using  dBASE  III+  is  implemented  on  an  IBM  PC.  It  is 
designed  for  the  user  who  does  not  have  computer  experience,  and  is  based  on  the 
theoretical  design  problems. 
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I.  INTRODUCTION 

The  influence  of  personnel  management  on  the  business  organization  has 
increased  appreciably  in  recent  years.  Much  of  this  increase  can  be  attributed  to  the 
growing  complexity  of  human  resource  management  and  the  issues  related  to  it.  In  the 
Republic  of  Korea(R.O.K),  in  order  to  strengthen  the  capability  of  combat  under  the 
limited  national  defense  expenditure,  it  is  imperative  that  personnel  management  be 
performed  very  efficiently.  To  achieve  this  goal,  the  high  level  managers  of  the  military 
very  often  need  a  variety  of  data  relevant  to  each  person.  Therefore,  a  modern 
database  management  system  is  needed  for  the  R.O.K  military  personnel  management 
system. 

The  database  management  systems  now  in  use  permit  greater  flexibility  in 
meeting  information  requirements,  faster  response  times,  and  easier  user  access  to 
stored  data  then  earlier  software  systems.  These  benefits  are  achieved  at  the  expense  of 
larger  capital  and  manpower  investments,  greater  system  complexity,  lower  processing 
efficiency,  and  long  pay  off  periods.  The  value  of  such  systems  can  not  be  determined 
strictly  on  money,  but  also  by  the  increase  in  the  number  of  applications  processed  for 
noncomputer  oriented  users.  Perhaps  the  most  exciting  development  to  occur  from  the 
introduction  of  such  systems  is  the  wide  availability  of  easy  to  use  query'  type 
languages  which  permit  nonprogrammers  to  create,  update,  maintain,  and  extract 
information  from  their  own  files. 

In  database  development,  it  should  be  possible  to  query  the  database  to  satisfy 
the  user's  requirements  using  application  programs  or  the  Database  Management 
System(DBMS)  itself  Because  there  are  many  types  of  data  structures,  models,  designs 
etc.,  we  should  select  one  which  depends  on  the  problem  or  situation.  The  normal 
form  concepts  of  relational  database  models  will  be  applied  to  develop  a  database  for 
the  Korean  military  personnel  management.  Most  experts  agree  that  the  relational 
data  model  supports  data  independence  better  than  other  models. 

This  thesis  will  focus  on  a  database  design  applying  a  Relational  Model  to  R.O.K 
Army  and  Air  Force  personnel  management.  The  actual  sample  data  of  R.O.K  Army 
personnel  will  be  used  for  implementing  the  sample  program  using  dBASE  III  +  .  In 
Chapter  II,  Background,  we  will  address  personnel  management  and  give  a  general 
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overview  of  a  database  system.  In  Chapter  III,  general  concept  of  the  Relational 
Model  will  be  discussed  and  in  Chapter  IV,  data  base  design  problems  mil  be  discussed 
in  detail  theoretically.  In  Chapter  V,  practical  system  analysis  and  relational  database 
design  for  Korean  Army  personnel  management  system  will  be  discussed.    In  Chapter 

VI,  we  will  discuss  and  show  example  for  data  base  implementation  and  in  Chapter 

VII,  processing  procedure  to  access  the  sample  program  in  Appendix  A  will  be  shown. 
In  Chapter  VIII,  conclusions  will  be  drawn  and  recommendations  for  implementation 
will  be  offered. 
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II.  BACKGROUND 

A.       PERSONNEL  MANAGEMENT 

1.  Basic  concept 

To  meet  organizational  objectives  it  is  necessary  to  continually  acquire  human 
resources;  integrate  employees  into  the  organization;  develop  employee  potential;  and 
maintain  the  work  force.  Personnel  management  is  an  integral  part  of  the  broader  field 
of  management.  Management  has  been  defined  as  the  process  of  accomplishing 
objectives  through  the  efforts  of  other  people  within  an  organization.  Thus,  we  can 
say  that  the  role  of  personnel  is  critical  for  managing  in  general.   [Ref  1:  p.  17] 

In  any  military'  hierarchy  there  are  many  levels  of  command  and  control.  Each  level 
has  its  own  duties  and  needs  adequate  number  of  people  with  respect  to  knowledge, 
capability,  rank,  skill  etc. 

2.  Objectives 

Objectives  are  the  starting  point  of  the  management  process.  They  give  the 
organization  and  its  people  a  purpose  and  direction.  Objectives  serve  to  guide 
managers  and  employees  in  their  efforts.  The  managers  commonly  perform  these 
functions: 

(1)  Planning  -  determining  strategies  and  programs  to  help  accomplish  established 
objectives. 

(2)  Organizing  -  grouping  and  assigning  activities,  staffing  the  organization,  and 
delegating''autTiority  to  carry  out  activities. 

(3)  Directing  -  encouraging  human  efforts  and  stimulating  accomplishment  of 
objectives. 

(4)  Controlling  -  measuring  accomplishments,  comparing  results  with  planned 
objectives.'determinmg  causes  of  deviations,  and.  taking  necessarv  corrective 
action. 

3.  Korean  Army  and  Air  Force  personnel  management 

The  Republic  of  Korea's(R.O.K)  Army  and  Air  Force  uses  the  general  staff 
model  which  includes  Personnel,  Intelligence,  Operations  and  Training,  and 
Logistics{Gl-G4).  The  R.O.K  government  spends  a  large  percentage  of  the  total 
government  budget  for  national  defense  and  the  Department  of  National  Defense 
spends  a  significant  portion  of  the  national  defense  expenditures  for  personnel. 

Personnel  managers  need  data  about  the  individual  personnel  capabiUty  and 
group  personnel  capability  to  analyze,  to  investigate,  to  plan,  and  to  apply  this  data  for 
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their  organizations.  Infcrmaiion  about  group  personnel  power  can  be  derived  by  a 
collection  of  individual  personnel  power.  It  is  important  to  increase  individual  and 
group  personnel  power  in  the  personnel  management  field  so  that  the  right  people 
move  into  the  right  jobs  at  the  right  times  and  under  the  right  circumstances. 
[Ref.  2:  p.73] 

In  the  military,  information  about  individual  personnel  power  can  be  derived 
from  functions  involving  procurement,  education  and  training,  assignment,  treatment, 
promotion  and  retirement.  In  order  to  reduce  the  national  defense  expenditure  and 
increase  the  war_mak.ing  capability,  the  Korean  military  needs  a  computerized 
management  information  system  personnel  management.  Therefore,  some  important 
functions  of  the  Army  and  Air  Force's  Department  o[  Personnel  Management  and 
other  essential  information  are  analyzed  as  system  requirements.  Information 
management  by  computer  is  very  important  for  fast  and  accurate  personnel 
management  in  the- Korean  military. 

B.       DATA  VERSUS  INFORMATION 

Data  and  information  are  meant  to  have  two  distinct  meanings.  Data  may  best 
be  thought  of  as  representing  objective,  external  realities  such  as  a  flash  of  lightning  in 
the  sky,  the  expression  on  an  employee's  face,  or  the  number  of  widgets  produced  per 
day  on  the  production  line.  Viewed  in  this  way,  data  becomes  pure  fact.  Data  is 
knowledge  for  the  sake  of  knowledge.  When  captured  and  stored,  data  is  merely  a 
record  of  these  specific  characteristics  and  events  which  can  be  reliably  observed  and 
which  have  sufficient  impact  to  be  taken  note  of 

On  the  other  hand,  the  term  "information"  may  be  restricted  to  mean  interpreted 
data.  Information  should  be  thought  of  as  the  statement  of  the  relationship  of  any 
given  characteristic  or  event  to  specific  goals  and  purposes.  It  is  what  is  used  to 
control  progress  toward  these  goals  and  objectives.  The  term  "information"  will  be 
reserved  to  mean  knowledge  for  the  sake  of  purposeful  action.  These  are  the  key 
definitions: 


Data  is  the  record  of  anv  reliablv  observable  characteristic  or  event  in  nature. 
Inlormation  is  the  description  of  the  relationship  of  anv  such  characteristic  or 
event  to  human  goals  ana  or  business  purposes  [Ref  3:  p.'124]. 


Figure  2.1,  shows  this  relationship. 

16 


12 

units 

$35, 

000 

J. 

Jones 

$12, 

000 

western  region | 

100  units 

$100,000 

35  units 

--  —  --> 


Data 


sales 

person:  J. 
territory: 

Jones 

sales 

western  regi 

on 

current  sales: 

$  147,000 

147  unit 

s 

Information 


Figure  2.1     Data  versus  Information. 

C.   GENERAL  OVERVIEW  OF  A  DATABASE  SYSTEM 

1 .  Introduction  .  . 

The  theory  of  data  management  predates  computers.  Early  attempts  at 
putting  the  theory'  into  practice  with  rudimentary  equipment  were  made  in  the  1940s 
and  early  1950s.  Computers  were  applied  to  the  management  of  data  in  late  1950s  and 
early  1960s.  These  computers  were  able  to  process  data  more  quickly  and  in  greater 
quantities  than  ever  before,  but  the  management  of  data  (storage,  manipulation  and 
retrieval)  was  still  quite  unsophisticated.  The  architecture  of  computers  at  that  time 
facihtated  sequential  processing  of  large  volumes  of  data  or  massive  computations 
made  on  small  amount  of  data,  one  job  at  a  time.  In  the  middle  1960s,  computer 
architecture  was  radically  changed.  A  quantum  increase  in  the  size  o[  computer 
memory  and  the  introduction  of  operating  systems  made  it  possible  for  computers  to 
do  more  than  one  job  concurrently.  This  kind  of  processing  called  multi-programming, 
has  continued  right  up  to  the  present. 

Concurrent  with  multi-programming  came  the  capacity  to  do  what  is  called 
"on-line"  or  single  transaction  processing.  Rather  than  process  large  volumes  of  data 
sequentially,  it  has  become  economically  feasible  to  access  specific  information  from 
computer  stored  files  within  seconds.  In  the  late  1960s,  more  sophisticated  methods  of 
storing  and  retrieving  data  were  incorporated  into  computer  software  (programs). 
These  programs  were  the  first  data  base  management  systems.  The  idea  was  just  a 
little  ahead  of  its  time.  Although  computer  memories  had  grown  in  size  from 
thousands  of  positions  to  hundreds  of  thousands,  they  were  not  quite  up  to  the  task. 
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However,  in  the  early  and  middle  1970s,  computer  meinory  capacities  were  such  that 
millions  of  characters  could  be  stored  in  them,  and  storage  technology  had  increased 
the  potential  size  even  further.  This  increase  has  made  possible  the  implementation  of 
data  management  software.  Since  it  has  become  technologically  possible  (and  is  at 
least  approaching  economic  feasibility),  the  concept  of  data  management  is  now 
emerging  in  the  business  community.  Technological  advances  are  making  it  possible  to 
store  data  in  a  way  that  is  radically  different  from  most  of  the  contemporary  methods 
now  in  use.  This  new  technology  is  manifesting  itself  in  both  hardware  and  software. 
Hardware  technology  is  allowing  for  large  amounts  of  data  (billions  of  characters)  to 
be  stored  on-line.  Software  technology  is  supplying  the  mechanisms  for  the  storing, 
updating  and  retrieving  of  that  data. 

The  mechanisms  for  manipulating  and  retrieving  data  (converting  data  to 
information)  are  known  as  Data  Base  Management  Systems(DBMS).  There  are  a 
number  of  software  packages  that  provide  these  mechanisms.   [Ref  4>  p.ll] 

2.  Data  base  si,'stem  definitions 

Data  base  terminology  and  data  base  theory  will  be  briefly  presented  in  this 
section.  To  facilitate  this  discussion,  it  is  necessar\'  to  set  some  common  definitions. 
They  are: 

(1)  Data  is.  a  group  of  non-random  svmbols  that  represent  quantities,  actions, 
thmgs.  facts',  concepts  or  instruction's  m  a  wav  suitable  for  communication  and 
proc~essin2  bv  humans  or  machines.  Information  is  data  that  has  been 
processed^and  presented,  as  described  in  B.  in  this  chapter. 

(2)  A  record  is  a  group  of  related  data  items. 

(3)  A  file  (data  set)  is  a  collection  of  related  records.  A  database  is  a  collection  of 
files  losicallv  related  in  such  a  way  as  to  improve  access  to  the  data  and 
minimize  redundancy  of  data. 

(4)  A  data  base  management  svstem  is  a  set  of  programs  that  function  to  create 

and  update  the  dala  base,  'retrieve  data  ana  senerate  reports  from  the  data 
base.  A  conceptual  model  (data  model)  is  a  representation  of  the  information 
content  of  the  data  base.    Figure  2.2  shows  the  composition  of  data  base. 

3.  What  is  DBMS? 

In  simple  terms,  it  is  a  computer  software  system  that  provides  control, 
retrieval  and  storage  of  data  contained  in  one  or  a  combination  of  data  files  that  are 
tied  together  by  the  DBMS  and  are  more  commonly  referred  to  as  a  data  base. 
Provided  by  the  computer  manufacturer  or  an  independent  software  house,  the 
software  package  is  adaptable  to  all  application  systems.  But  DBMS  can  be  truly 
understood  by  contrasting  it  with  traditional  practices. 

The  ordinary  systems  development  approach  has  been  to  organize  data  into 
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Figure  2.2    Composition  ofdatabase^ 

individual  files,  with  the  typical  business  data  processing  center  developing  around  the 
computerization  of  separate  applications  such  as  payroll,  inventory,  and  accounts 
receivable.  What  happens,  however,  is  that  the  computer  data  files  necessary  to 
support  these  applications  are  fixed  in  their  structure  with  preset  formats  frozen  into 
the  computer  programs.  The  result  has  been  that  when  a  range  of  data  values  has 
grown  to  the  point  where,  let  us  say,  one  more  digit  position  is  required,  there  may  be 


Roberstone,   Debra   Lj.   Daia  Dictionary  Svsiems  and  their  role  in  information 
resource  management.  Naval  Postgraduate  School, 'Mar  1984 
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no  available  physical  space  in  the  file  record.  The  entire  computerized  data  record 
must  then  either  be  expanded  or  redesigned,  and  this  new  design  in  turn  leads  to 
related  changes  in  all  computer  programs  that  use  these  computer  data  files. 
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Figure  2.3     Example  of  File  Processing  Systems(pre-database). 
James  Martin,  a  well  known  author  in  the  data  base  field,  defined  a  data  base 


a  collection  of  interrelated  data  stored  together  without  unnecessarv  redundancy 
to  serve  multiple  applications.  The  data  are  stored  so  that  thev  are  independent 
of  the  programs  which  use  them.   A  common  and  controlled  approach  is  used  in 


addmg  new  data  and  modifvine  and  retrieving  existing  data.  The  data  i 
structured  so  as  to  provide  a  foundation  for  future  application  developmei 
[Rcf  5:  p.22]  ^  '  ^  ^ 


are 
ment. 


Figure  2.3  and  Figure  2.4  show  the  characteristics  of  database  processing  system. 


.        Kroenke.  David  M.,  Database  Processing:  Fundamentals,  Design,  Implementation, 
Science  Research  Associates  INC.,  1983,  p.2 
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4.  DBMS  characteristics 

The  current  science  clearly  demands  an  environment  that  is  quite  diflerent  and 

features  flexibility  and  expandabihty  -  inherent  features  in  a  data  base  management 

system.   Specifically,  DBMS  possesses  the  following  characteristics: 

(1)  Data  shareability.  Through  the  structuring  of  data  bases  and  control  of  the 
DBMS,  data  may  be  shared  among  many  mdependent  computer  applications. 
Since  some  applications  may  not  oe  planned  until  well  after  the  completion 
and  installation  of  other  applications  that  use  the  same  data  bases,  computer 
programs  must  have  the  abilitv  to  use  comnionly  available  data.  Provision  is 
iher^efore  made  for  multinje  lises  of  the  same  data,  but  control  is  exercised 
over  access  and  over  interlaces  between  independent  programs. 
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Figure  2.4     Example  of  Data  Base  Processing  System' 


(2)  Data  independence.  A  seemingly  trivial  application  design  change  or  database 
expansion  can  have  an  undesirable  cost  impact.  Hence,  it  is  important  to 
avoid  dependence  of  computer  protzrams  on  a  fixed  phvsical  data  base. 
DB.VIS  permits  the  addition  and  cfeletlon  of  the  data  base,  data  fields  or  data 
records  without  modifying  existing  computer  programs. 

(3)  Control  of  data  redundancy,  proliferation  of  similar  data  as  more  and  more 
data  bases  are  integrated.  While  not  eliminating  all  redundancv,  DBMS 
avoids  much  of  this"T3v  structuring  common  data  needs  is  terms  of  so-called 
logical  data  relationships  that  avoid  duplicate  data  values. 


^Kroenke,  David  M.,  Database  Processing:  Fundamentals,  Design,  Implementation, 
Science  Research  Associates  INC.,  1983,  p.4 
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(4)  Data  intesrity  and  security.  In  as  many  users  share  the  same  data  files, 
DBMS  rnaintains  control  over  the  integritv  of  the  data  base  throueh 
synchronization  of  updates,  insuring  validity  of  data,  examining  the 
propagation  of  changes  to  data  item  values  or  to  dependent  data  items,  and 
maihtainine  an  audit  trial  of  interfaces  between  programs  and  data.  Data 
security  measures  must  also  be  applied  to  all  DBVIS"  structures,  recognizing 
that  accessibility  to  data  should  be  a  function  of  the  sensitivitv  of  the  data,  the 
processing  procedures,  and  the  authority  of  the  user.  Tirriing  intervals  for 
duplicating  all  data  bases  must  be  specified  and  provision  made  for  on- 
promise  as  well  as  off-promise  storage  for  back  up  purposes. 

Database  technology  allows  an  organization's  data  to  be  processed  as  an 

integrated   whole.     It    reduces    artificiality   imposed    by    separate    files    for    separate 

applications  and  permits  users  to  access  data  more  naturally.    Data  integration  offers 

several  important  advantages: 

More  information  from  the  same  amount  of  data 

New  reports  and  one-a-kind  requests  more  easily  implemented 

Elimination  of  data  duplication 

Program/ Data  independence 

Better  data  management 

Affordable, sophisticated  programming 

Representation  of  record  relationships 

On  the  other  hand,  database  processing  has  a  few  disadvantages: 

Expensive  database  management  system 

Higher  operating  cost 

Complexity 

Recovery  is  more  difficult 

Increased  vulnerability  to  failure 
5.  Levels  of  abstraction  in  a  DBMS 

A  fairly  standard  viewpoint  regarding  levels  of  abstraction  is  shown  in  Figure 
2.5.  [Ref  6:  p.3]  There  we  see  a  single  database,  which  may  be  one  of  many  databases 
using  the  same  DBMS  software,  at  three  different  levels  of  abstraction.  The 
conceptual  database  is  an  abstract  representation  of  the  physical  database  (or, 
equivalently,  we  may  say  the  physical  database  is  an  implementation  of  the  conceptual 
database),  and  the  views  are  each  abstraction  of  portions  of  the  conceptual  database. 
The  difference  in  the  level  of  abstraction  between  views  and  the  conceptual  database  is 
generally  not  great. 

The  term  scheme  is  used  to  refer  to  plans,  so  we  talk  of  a  conceptual  scheme 
as  the  plan  for  the  conceptual  database,  and  we  call  the  physical  database  plan  a 
physical  scheme.   The  plan  for  a  view  is  often  referred  to  simply  as  a  subscheme. 
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a.    The  conceptual  scheme  and  its  model 
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Figure  2.5     Levels  of  Abstraction  in  A  Database  System"^. 

As  we  have  said,  the  conceptual  scheme  is  an  abstraction  of  the  real  world 
pertinent  to  an  organization  like  enterprise.  A  DBMS  provides  a  data  d'efinition 
language  to  specify  the  conceptual  scheme  and,  most  likely,  some  of  the  details 
regarding  the  implementation  of  the  conceptual  scheme  by  the  physical  scheme.  The 
data  defmition  language  is  a  high-level  language,  enabling  one  to  describe  the 
conceptual  scheme  in  terms  of  a  "data  model". 
b.    Views 

A  view  or  subscheme  is  an  abstract  model  of  a  portion  of  the  conceptual 
database  or  conceptual  scheme.  For  example,  an  airline  may  provide  a  computerized 
reservation  service,  consisting  of  data  and  a  collection  of  programs  that  deal  with 
flights  and  passengers.  These  programs,  and  the  people  who  use  them,  do  not  need  to 
know  about  personnel  files  or  the  assignment  of  pilots  to  flights.  The  dispatcher  may 
need  to  know  about  flights,  aircraft,  and  aspects  of  the  personnel  files  (e.g.,  which 
pilots  are  qualified  to  fly  a  747),  but  does  not  need  to  know  about  personnel  salaries  or 
the  passengers  booked  on  a  flight. 


'^Ullman.  Jeflery  D.,  Principles  of  database  system,  Computer  Science  Press  INC., 
1980,  p.3 
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f.    The  physical  database 

At  the  lowest  level  of  abstraction  with  which  we  deal,  there  is  a  physical 
database.  The  physical  database  resides  permanently  on  secondary  storage  devices, 
such  as  disks  and  tapes.  We  may  view  the  physical  database  itself  at  several  levels  of 
abstraction,  ranging  from  that  of  records  and  files  in  a  programming  language  such  as 
PL/I,  perhaps  through  the  level  of  logical  records,  as  supported  by  the  operating 
system  underlying  the  DBMS,  down  to  the  level  of  bits  and  physical  addresses  on 
storage  devices. 

6.  The  objectives  of  database  system  organizations 

A  database  system  should  be  the  repository  of  the  data  needed  for  an 
organization's  data  processing.  That  data  should  be  accurate,  private,  and  protected 
from  damage.  The  system  should  be  designed  so  that  diverse  applications  with 
different  data;  information  requirements  can  employ  the  data.  DifTerent  end-users  have 
different  views  of  data  which  should  be  derived  from  a  common  overall  data  structure. 
In  order  to  achieve  these  user  requirements  and  others,  the  following  objectives  are 
considered  by  database  system  designers.   [Ref.  7:  p. 34] 

(1)  The  database  is  THE  FOUNDATION  OF  FUTURE  APPLICATION 
DEVELOPMENT.  It  should  make  application  development  easier,  cheaper, 
faster,  and  more  flexible. 

(2)  THE  DATA  CAN  HAVE  MULTIPLE  USES.  Different  users  who  perceive 
the  same  data  differently  can  employ  them  in  different  ways. 

(3)  CLARITY.  Users  can  easily  determine  and  understand  what  data  are 
available  to  them. 

(4)  E.A.SE  OF  USE.  Users  can  gain  access  to  data  in  a  simple  fashion. 
Complexity  is  hidden  from  the  users  by  the  DBMS. 

(5)  FLEXIBLE  USAGE.  The  data  can  be  used  or  searched  in  several  ways  with 
diflerent  access  paths. 

(6)  CHANGE  IS  EASY.  The  database  can  erow  and  change  without  interfering 
with  establisiied  procedures  for  using  the  data. 

(7)  LOW  COST.  The  cost  of  storing  and  using  data,  and  the  cost  of  making 
changes,  must  be  as  small  as  possible. 

(8)  LESS  DATA  PROLIFER.^TION.  New  application  needs  may  be  met  with 
existing  data  rather  than  creating  new  files,  thus  avoiding  the  excessive 
proliferation  in  today's  tape  libraries. 

(9)  PERFOR.VIANCE.  Data  requests  can  be  satisfied  with  speed  suitable  to  the 
usage  of  the  data. 

(10)  PRIVACY.    Unauthorized  access  to  the  data  will  be  prevented.    The  same 
data  should  be  restricted  in  diilerent  ways  from  different  uses. 

(11)  AVAILABILITY.    Data  should  be  available  to  users  at  the  time  when  thev 
need  them. 
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(12)  RELIABILITY.  Almost  all  information/data  for  personnel  management  is 
very  imiportant  to  both  individual  personnel  (e.g.  Tor  promotion,  for  new 
assignment,  etc.)  and  group  personnel.  The  information  which  is  derived  from 
database  processing  must  oe  very  reliable. 

D.       DATABASE  MODEL 

A  data  model  is  a  collection  of  data  structures  together  with  a  collection  of 
operations  that  manipulate  the  data  structures  for  the  purpose  of  storing,  querying,  or 
processing  the  structure  contents.  A  data  model  may  also  include  the  integrity 
constraints  defined  over  the  data  structures,  or  it  may  include  access  control  facilities 
of  mechanisms  for  defining  various  external  user  views  of  the  database.  Some  data 
models  provide  physical  storage  structures  and  physical  access  methods  as  part  of  the 
data  model,  but  usually  a  data  model  is  limited  to  the  data  structures  and  operations 
that  are  available  to  an  end  user  and  may  be  accessed  from  an  application  program. 
There  are  two  reasons  for  studying  database  models.  First,  they  are  an  important 
database  design  tool.  Database  models  can  be  used  for  both  logical  and  physical 
database  design  -  much  as  fiow  charts  or  pseudocode  are  used  for  program  design. 
Second,  database  models  are  used  to  categorize  DBMS  products.  In  this  section,  we 
will  discuss  the  components  of  a  database  model  and  survey  six  important  models. 

1.  Component  of  database  model 

Database  models  have  two  major  components.  The  Data  Definition 
Language  (DDL)  is  a  vocabulary  for  defining  the  structure  of  the  database.  The  DDL 
must  include  terms  for  defining  records,  fields,  keys,  and  relationships.  In  addition  the 
DDL  should  provide  a  facility  for  expressing  database  constraints.  Data  Manipulation 
Language  (DML)  is  the  second  component  of  a  database  model.  The  DML  is  a 
vocabulary  for  describing  the  processing  of  the  database.  Facilities  are  needed  to 
retrieve  and  change  database  data.  There  are  two  types  of  DML.  procedural  DML 
and  nonprocedural  DML.  Procedural  DML  is  a  language  for  describing  actions  to  be 
performed  on  the  database.  Procedural  DML  obtains  a  described  result  by  specifying 
operations  to  be  performed.  For  procedural  DML,  facilities  are  needed  to  define  the 
data  to  be  operated  on  and  to  express  the  actions  to  be  taken.  Both  data  items  and 
relationships  can  be  accessed  or  modified.  Nonprocedural  DML  is  a  language  for 
describing  the  data  that  is  wanted  without  describing  how  to  obtain  it. 

2.  Prominent  database  models. 

Figure  2.6  portrays  six  common  and  useful  database  models.  Models  on  the 
left-hand  side  of  this  figure  tend  to  be  oriented  to  humans  and  human  meaning, 
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whereas  those  on  the  right-hand  side  are  more  oriented  toward  machines  and  macliine 
specifications. 
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Figure  2.6     Relationship  of  Six  Important  Data  Models. 

a.  Relational  data  model 

The  relational  database  model  is  near  the  midpoint  of  the  human/machine 
continuum  in  Figure  2.9,  because  it  has  both  logical  and  physical  characteristics.  The 
relational  model  is  logical  in  that  data  are  represented  in  a  format  familiar  to  humans; 
the  relational  model  is  unconcerned  with  how  the  data  are  represented  in  computer 
files.  On  the  other  hand,  this  is  more  physical  than  SDM(semantic  data  model)  or  the 
E_R(entity  relationship)  model.  Database  that  have  been  designed  according  to  the 
relational  need  not  be  transformed  into  some  other  format  before  implementation. 
Thus  the  relational  model  can  be  used  for  both  logical  and  physical  database  design.  A 
relation  is  simply  a  Hat  file.  The  rows  of  the  relation  are  the  file  records.  Rows  are 
sometimes  called  tuples  of  the  relation.  The  field  of  the  relation  (in  the  columns)  are 
sometimes  called  the  attributes  of  the  relation.  The  significance  of  the  relational  model 
is  not  that  data  are  arranged  in  relations  but  that  relationships  are  concerned  to  be 
implied  by  data  values.  The  principle  advantage  of  carr\'ing  relationships  in  data  is 
fiexibiUty.   Relationships  need  not  be  predefined.   [Ref.  7:  p.  196] 

b.  Semantic  data  model 

The  word  semantic  means  meaning.  The  semantic  data  model  provides  a 
vocabulary  for  expressing  the  meaning  as  well  as  the  structure  of  database  data.    .As 


26 


such,  SDM  is  useful  for  logical  database  design  and  documentation.  SDM  provides  a 
precise  documentaiion  and  ccmmunication  medium  for  database  users.  In  particular,  a 
new  user  of  a  large  and  complex  database  should  find  its  SDM  schema  of  use  in 
determining  what  information  is  contained  in  the  database.  Also,  SDM  provides  the 
basis  for  a  variety  of  high  level  semantics-based  user  interfaces  to  a  database.  SDM 
has  been  designed  to  satisfy  a  number  of  criteria  that  are  not  met  by  contemporary 
database  models.  The  chief  advantage  of  SDM  is  that  it  provides  a  facility  for 
expressing  meaning  about  the  data  in  the  database.  Another  advantage  of  SDM  is 
that  it  allows  data  to  be  described  in  context.  Users  see  data  from  different 
perspectives.  They  see  it  relative  to  their  field  of  operation.  SDM  allows  relative  data 
definition.  A  third  advantage  of  SDM  is  that  constraints  on  database  data  can  be 
defined.  For  example,  if  a  given  item  is  not  changeable,  SDM  allows  this  fact  to  be 
stated.  With  other  data  models,  such  constraints  are  not  part  of  the  schema 
description  and  are  documented  separately.  SDM  is  like  a  pseudocode.  But, instead  of 
describing  the  structure  of  programs  as  pseudocode  does, SDM  describes  the  structure 
of  data.  Like  pseudocode.  SDM  has  certain  structures  and  rules,  and  withm  those 
structures  and  rules,  the  designer  has  a  good  deal  of  latitude  and  flexibility. 
[Ref  7:  p.  193] 

c.   Entity   -    Relationship  model 

The  entity-  relationship  model(E-R  model)  is  primarily  a  logical  database 
model,  although  it  has  some  aspects  of  a  physical  model  as  well.  As  its  name  implies, 
the  E-R  model  is  explicit  about  relationship.  Unlike  SDM,  in  the  E-R  model  both 
entities  and  relationships  are  considered  to  be  different  constructs.  Entities  are 
grouped  into  entity  sets,  and  relationships  are  grouped  into  relationship  sets.  An 
entity-relationship  diagram  is  a  graphical  portrayal  of  entities  and  their  relationships. 
It  is  useful  to  summarize  the  information  in  a  design.  It  supports  the  representation  of 
more  general  relationships.   [Ref  7:  p.  194] 

J.    CODASYL  DBTG  model 

The  CODASYL  DBTG( conference  on  Data  System  Languages.  Database 
Task  Group)  data  model  was  developed  by  the  same  group  that  formulated  COBOL 
during  the  late  1960s  and  is  the  oldest  of  the  data  models.  The  DBTG  model  is  a 
physical  database  model.  There  are  constructs  for  defining  physical  characteristics  of 
data,  for  describing  where  data  should  be  located,  for  instructing  the  DBMS  regarding 
what  data  structures  to  use  for  implementing  record  relationships,  and  other  similar 


27 


physical  characteristics.  A  DBTG  schema  is  the  collection  of  all  records  and 
relationships.  A  subschema  is  a  subset  and  reordering  of  records  and  relationships  in 
the  schema.  Unlike  the  relational  model,  relationships  become  fixed  when  they  are 
defined  in  the  schema.  Several  reasons  account  for  the  lukewarm  response  that  the 
CODASYL  model  has  received,  including  the  fact  that  it  has  a  decidedly  COBOL 
flavor  to  it.  Finally,although  most  of  the  core  concepts  of  the  model  are  defined  and 
agreed  upon,  there  are  many  not-agreed-on  variants  of  the  core  concepts.  These 
variants  create  confusion  and  lead  to  a  dilemma.  [Ref.  7:  p.  197] 
e.   DBMS-specific  models 

There  are  over  one  hundred  different  commercial  DBMS  products.  The 
DBMS  are  sometimes  categorized  in  terms  of  their  underlying  data  model.  A  DBMS  is 
considered  a  relational  system  if  it  conforms,  in  essence,  to  the  relational  data  model. 
Alternately,  a  DBMS  is  considered  to  be  a  CODASYL  system  if  it  conforms,  in 
essence,  to  the  CODASYL  DBTG  data  model.  A  third  category  of  DBMS  is  other.  If 
a  DBMS  does  not  conform  to  one  of  the  above  two  data  models,  then  it  has  its  owti, 
unique  data  model.  There  are  many  systems  that  fall  into  the  other  category. 
[Ref  7:  p.  198] 

/.   ANSIIX3 1  SPARC  data  model 

The  ANSI/X3/SPARC(American  National  Standards  Institute  /  Committee 
X3  /  Standards  Planning  and  Requirements  (sub)-Committee)  data  model  does  support 
a  variety  of  different  data  models  in  Figure  2.6.  This  model  is  a  model  for  DBMS 
design  rather  than  for  database  design.  This  have  the  external,  conceptual,  and 
internal  schema.   [Ref  7:  p.  198] 
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III.  RELATIONAL  MODEL 

A.       INTRODUCTION 

A  relation  is  a  mathemadcal  term  for  a  two-dimensional  table.  It  is  characterised 
by  rows  and  columns,  each  entry  there  being  a  data  item  value.  The  reason  for  calling 
this  a  relation  rather  than  a  matrix  lies  in  the  lack  of  homogeneity  in  its  entries  -  the 
entries  are  homogeneous  in  the  columns  but  not  in  the  rows.  A  relational  data  base 
consists  of  such  relations,  which  can  be  stored  on  a  physical  device  in  a  variety  of 
ways. 

From  the  late  1960s  a  number  of  people  toyed  with  the  idea  of  constructing  data 
base  with  relations  as  the  basic  building  blocks.  Most  of  these  early  systems  were 
restricted  to  relations  vnth  only  two  columns,  and  all  of  them  were  special-purpose 
models  incapable  of  meeting  general  data-processing  requirements.  In  1970  E.F.  Codd 
of  IBM  proposed  a  model  for  a  generalised  relational  Data  Base  System  chiefly  to 
provide  data  independence  and  data  consistency,  which  are  difficult  to  achieve  m  the 
formatted  Data  Base  Systems.  The  model  was  subsequently  improved  and  expanded 
by  Codd  and  is  now  regarded  by  many  as  the  future  of  all  Data  Base  Systems. 
Needless  to  say,  the  term  relational  data  base  or  relational  model  is  nowadays  generally 
indentified  with  Codd's  model  alone. 

A  basic  feature  of  the  relational  model  is  its  simplicity.  A  relation  is  a  table  of 
data  and  it  may  consist  of  only  one  row  and  one  column,  thus  providing  the  simplest 
possible  data  structure  which  can  be  used  as  the  common  denominator  of  all  data 
structures.  It  simplifies  the  design  of  the  schema  since  there  is  only  one  logical  data 
structure-the  relation-to  consider,  without  having  to  worr\'  about  the  construction  of 
the  right  data  structures  to  represent  complex  data  relationships.  Furthermore  the 
relational  model  provides  an  unparalleled  freedom  to  the  application  programer  by 
enabling  him  to  access  any  data  item  value  in  the  data  base  directly,  the  access 
mechanism  being  associative  or  content  addressable  since  a  data  item  is  accessed 
directly  by  its  value  rather  than  by  its  relative  position  or  by  a  pointer. 

The  concepts  of  the  relational  model  are  founded  on  mathematics,  and  all  the 
terms  used  are  mathematical.  This  has  the  etTect  of  scaring  off  most  people  who  would 
normally  be  interested  in  a  data  base. 
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In  this  chapter  we  shall  keep  the  involvement  with  mathematics  to  a  minimum. 

All  concepts  will   be  defined   in  non-mathematical   terms  in   a   simplified   manner, 

sacrificing  in  the  process  some  of  the  mathematical  rigour  which  is  really  unnecessary 

•for  the  understanding  of  the  model,   we  shall  also  give  the  data-processing  equivalent 

of  the  commonly  used  relational  concepts. 

B.       BASIC  CONCEPT 

1.  Terminology 

A  relation  is  simply  a  two-dimensional  table  that  has  several  properties.  First, 
the  entries  in  the  table  are  single-valued;  neither  repeating  groups  nor  arrays  are 
allowed.  Second,  the  entries  in  any  column  are  all  of  the  same  kind.  For  example,  one 
column  may  contain  person  numbers,  and  another  ages.  Further,  each  column  has  a 
unique  name  and  the  other  of  the  columns  is  immaterial.  Columns  of  a  relation  are 
referred  to  as  attributes.  Finally,  no  two  rows  in  the  table  are  identical  and  the  order 
of  the  rows  is  insignificant.    Figure  3.1  portrays  a  relation. 


Name 

MSN 

Rank 

Age 

Jae  B.  Park 

667423 

Capt 

30 

Sam  N.  Kim 

651242 

Maj 

33 

Young  S.  Jung 

652310 

Maj 

34 

Tae  H.  Choi 

632258 

Col 

44 

Figure  3.1     Korean  Military  Person  Relation. 

Each  row  of  the  relation  is  known  as  a  tuple.  If  the  relation  has  n  columns  or 
n  attributes  is  said  to  be  of  degree  n.  The  relation  in  Figure  3.1  is  of  degree  4,  and 
each  row  is  a  4-tuple. 

Each  attribute  has  a  domain,  which  is  the  set  of  values  that  the  attribute  can 
have.  For  example,  the  domain  of  the  Rank  attribute  in  Figure  3.1  is  the  three  values, 
Capt,  Maj  and  Col.  The  domain  of  the  Age  attribute  is  all  positive  integers  less 
then, say,  100.  . 
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A  relation  of  degree  n  has  n  domains,  not  all  of  which  need  be  unique.  For 
example,  the  relation  in  Figure  3.2  has  age  and  age  of  spouse  attributes.  The  domains 
of  the  two  attributes  are  the  same,  integers  from  1  to  100.  To  differentiate  between 
attributes  that  have  the  same  domain,  each  is  given  a  unique  attribute  name.  The 
attribute  names  for  the  relation  in  Figure  3.2  are  Name,  Position,  Spouse-name,  Age, 
Spouse-age,  and  Unit. 


Name 

Position 

S_name 

Age 

S_age 

Unit 

■ 

Jae  B.  Park 

A 

Eun  K.  LEE 

30 

25 

212SQ 

Sam  N.  Kim 

B 

ki  0.  Sin 

33 

28 

117SQ 

You  S.  Jung 

C 

Hye  S.  Lee 

34 

29 

808SQ 

Tae  H.  Choi 

D 

Myen  J.  Cho 

44 

42 

512SQ 

'  Figure  3.2     Korean  Air  Force  Pilot  Relation. 

Figures  3.1  and  3.2  are  examples,  or  occurences.  The  generalized  format, 
KOREAN  MILITARY  PERSON  (Name,  MSN,  Rank,  Age),  is  called  the  relation 
structure,  and  is  what  most  people  mean  when  they  use  the  term  relation.  If  we  add 
constraints  on  allowable  data  values  to  the  relation  structure,  we  then  have  a  relational 
schema.   [Ref.  7:  pp243,245] 

As  mentioned  earlier,  a  relation  is  a  mathematical  term  used  to  define  a 
special  kind  of  table.  Each  column  is  called  a  domain  containing  all  the  values  of  an 
attribute,  and  each  row  a  tuple.  The  word  tuple  is  taken  from  the  description  of 
groups,  such  as  quintuple  and  sextuple.  Thus  a  group  of  n  elements  is  an  n-tuple.  In 
a  relation  of  n  domains,  each  tuple,  that  is,  each  row,  is  an  n-tuple.  The  number  of 
rows  or  tuples  in  a  relation  is  its  cardinality,  and  the  number  of  columns  is  its  degree. 
The  individual  elements  in  a  relation  are  attributes  values.  If  we  consider  an  m  x  n 
relation  (  m  rows  and  n  columns  ),  we  have. 

a  relation  of  degree  n  and  cardinality  m,  that  is, 
a  relation  containing  n  domains  and  n  tuples,  each 
tuple  being  an  n-tuple.   There  are  m  x  n  attribute 
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values,  each  tuple  having  n  columns  or  n  attribute 
values. 

A  relation  of  degree  1  is  called  unary,  degree  2  binary,  degree  3  ternary  and 
degree  n  n-ar>'  relation.  The  characteristics  of  a  relation  are  as  follows. 

(1)  All  entries  in  a  domain  are  of  the  same  kind. 

(2)  Domains  are  assigned  distinct  names  called  attribute-names. 

(3)  The  ordering  of  the  domains  is  immaterial. 

(4)  Each  tuple  is  distinct,  that  is,  duplicate  tuples  are  not  allowed. 

(5)  The  ordering  of  the  tuples  is  immaterial.   [Ref  8:  p.  132] 

2.  Attribute  and  domain  names 

A  domain  , unlike  a  tuple,  can  be  duplicate.  A  domain  name  is  the  common 
name  for  identical  domains  whereas  an  attribute  name  is  the  unique  name  for  an 
individual  domain.  Attribute  names  for  identical  domains  are  constructed  from  the 
common  domain  name  by  attaching  suitable  prefixes  to  it.  Consider,  for  instance,  a 
relation  called  HIERARCHY  containing  two  identical  domains  -  one  for  the  superior 
unit  number  and  the  other  for  subordinate  unit  number  -  both  holding  the  same  type 
of  information,  that  is,  unit  number  codes.  If  we  assume  a  common  domain  name, 
UNIT,  then  we  can  construct  two  attribute  names,  SUP-UNIT  for  the  superior  unit 
numbers,  and  SUB-UNIT  for  the  subordinate  unit  numbers.  Unit  code,  for  instance,  is 
DIV  for  division,  IRE  for  infantry  regiment,  ARE  for  artillery  regiment,  IBA  for 
infantry  battalion,  ABA  for  artillery  battalion  etc.  Using  QUANTITY  as  the  attribute 
name  for  the  third  domain  which  contains  the  numbers  of  a  subordinate  unit  numbers 
present  in  its  superior  unit  number,  we  can  represent  the  triplet  as  shown  in  Figure  3.3. 

From  the  mathematical  point  of  view,  a  domain  can  be  simple  or  non  simple, 
a  simple  domain  containing  a  single  attribute  and  a  nonsimple  domain  containing  a 
repeating  group  or  a  multiple  of  attributes.  Therefore  the  name  of  a  simple  domain 
can  be  identical  with  that  of  its  attribute.  A  nonsimple  domain  can  be  broken  down 
into  simple  domains,  giving  each  a  unique  attribute  name  as  we  have  done  in  the 
example  above. 

3.  Keys  and  attributes 

A  tuple  is  identified  by  its  key,  constructed  from  a  combination  of  one  or 
more  attributes  so  that  no  attribute  there  is  redundant.  .A.  tuple  can  have  more  than 
one  possible  key,  each  of  which  can  uniquely  identify  the  tuple.  All  these  possible  keys 
are  known  as  the  candidate  keys.    One  of  these  keys  is  arbitrarily  selected  to  identify 
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HIERARCHY  (  SUP_UNIT 

SUB_UNIT 

QUANTITY  ) 

DIV  102 

IRE  572 

6 

DIV  104 

ARE  337 

3 

ARE  337 

ABA  325 

5 

IRE  572 

IBA  153 

5 

Figure  3.3     A  Relation  of  Degree  3. 

the  tuple  and  this  key  is  known  as  the  primary  key.    For  example,  consider  a  tuple  with 
the  following  attributes 

Division  Code,  Regiment  Code,  Regiment  Commander  No. , 

No.  of  people. 

If  we  assume  that  every  regiment  has  its  own  separate  commander,  then  this 
tuple  can  be  uniquely  identified  either  by  Division  Code  +  Regiment  Code  ,  or 
Division  Code  +  Regiment  Commander  No.  These  then  are  two  candidate  keys,  one 
of  which  can  be  selected  as  the  primary  key.  Since  a  key  must  not  contain  redundant 
attributes,  the  Regiment  Code  and  Regiment  Commander  No.  can  not  appear  in  the 
same  key,  because  the  Regiment  Commander  No.  implicitly  defines  Regiment  Code. 

If  a  tuple  has  attributes  whose  combination  is  the  primary  key  in  another 
relation,  then  this  combination  is  called  a  foreign  key.  For  instance  Division  Code  can 
be  a  foreign  key.  An  attribute  that  forms  a  part  of  a  candidate  key  is  a  prime 
attribute  of  the  tuple.  The  other  attributes  are  nonprime.  In  the  example  given  above, 
the  Division  Code,  Regiment  Code  and  Regiment  Commander  No.  are  prime 
attributes,  and  the  No.  of  people  is  a  nonprime  attribute. 
4.  Comparison  with  standard  data-processing  concepts 

In  data-processing  terms  we  may  approximate  a  relation  to  the  occurrences  of 
a  record  type,  a  tuple  to  a  record  occurrence,  and  an  attribute  to  a  data  item,  a  domain 
being  the  collection  of  all  values  for  a  single  data  item.  Degree  is  the  number  of  data 
items  in  the  record  and  cardinality  is  the  total  number  of  records  in  the  record  type.  A 
unary  record  relation  is  a  record  type  consisting  of  a  single  data  item;  a  binary  relation 
is  a  record'type  of  two  data  items;  and  so  on. 
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However,  there  are  some  diOerences  between  record  types  and  relations  in 
third  normal  form,  a  record  type  being  equivalent  to  an  unnormalised  relation  where 
repeating  groups  are  permitted.  Normalised  form  will  be  discussed  in  Chapter  IV.  The 
ordering  oC  the  data  items-that  is,  their  relative  positions-is  fixed  in  a  record  type  and 
cannot  be  altered,  but  the  domains  of  a  relations  are  independent  of  their  relative 
positions  since  they  are  addressed  individually  by  their  attribute  names.  In  a  relation, 
the  ordering  of  tuples  is  also  unimportant  because  each  of  them  is  accessed  directly, 
but  this  is  not  generally  true  for  the  records  of  a  record  type,  unless  they  are 
specifically  stored  for  direct  retrieval.  These  access  advantages  follow  directly  from  the 
content-addressable  accessing  concept  used  in  relations  as  mentioned  earlier.  Finally 
by  definition  a  relation  can  have  a  duplicate  tuple,  but  there  is  no  such  conceptual 
restriction  on  the  existence  of  a  duplicate  record  in  a  record  type.  These  discussions 
are  summerized  in  Figures  3.4  and  3.5.   [Ref  8:  p.l34] 


Relational  Terms 

Data-processing  Terms 

Relation 

All  the  occurence  of  a  recorde  type 

Tuple 

Record 

Attribute 

Data  item 

Domain 

All  the  values  of  a  data  item 

Degree 

Number  of  data  items  in  the 
record  type 

Cardinality 

Total  number  of  records  in  the 

record  type 

1 

Figure  3.4    Equivalence  of  relational  terms  with  data-processing  concepts^. 


iv^   i^P^?^,,^-  ^^-r  Fundamenials  of  Database  Systems,  p.  134,Iiayden  book  company 
INC., Rochelle  park,  New  Jersy  1973  ^  .  f        .      ;'  t-     ;- 
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Item 

Relation 

Record  type 

Repeating  group 

Not  allowed  in 

Allowed 

normalised  relations 

Odering  of 

Immaterial 

Important 

domains  or  data 

items 

Ordering  of 

Immaterial 

Important 

tuples  or  records 

Duplicate  tuple 

Not  Allowed 

Immaterial 

or  record 

• 

Figure  3.5    DifTerence  between  relation  and  data-processing  concepts^ 


C.       EXPRESSING  RELATIONSHIPS  WITH  THE  RELATIONAL  MODEL 

When  we  design  a  database,  we  may  need  to  specify  tiie  logical  relationships  that 
will  exist  among  data  base  records.  When  we  consider  the  user's  requirement,  we 
should  realize  that  there  are  three  fundamental  types  of  record  relationships.  These 
types  are:  tree(  or  hierarchy  ),  simple  network,  and  complex  network. 

Many  relations  which  are  based  on  those  three  types  of  record  relationships  will 
be  discussed  in  this  section.    First  of  all,  each  type  of  relationship  is: 

(1)  Trees  or  hierarchies.  A  tree  is  a  collection  of  records  and  one-to-many 
relationships  among  records.  According  to  standard  terminoloav,  the  records 
are  called  nodes,  and  the  relationship  between  the  records  are  called  branches. 
The  node  at  the  top  of  the  tree  is  called  the  root.  Every  node  ol'  a  tree  has  a 
parent-the  node  immediately  above  it.    Figure  3.6  shows 'a  tree  relationship. 

(2)  Simple  Networks.  A  simple  network  is  also  a  collection  of  records  and  one- 
to-many  relationships  among  records.  In  a  simple  network,  a  record  mav 
have  niore.than  one  parent,  as  long  as  the  parents  are  diflerent  types  of 
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^Deen  S.  M.,  Fundamentals  of  Database  Systems,  p.  134,IIayden  book  company 
'..Rochelle  park,  New  Jersey  19/3 
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Tactical  Fighter  Wing 


1st  Tactical  Fighter  SQ 


2nd  Tactical  Fighter  SqJ  .  .  . 


pilot  1 


pilot  2 


pilot  10 


Figure  3.6     Example  of  Tree  Relationship. 

records.    Figure  3.7  shows  a  simple  network  relationship. 

(3)  Complex  Networks.  A  complex  network  is  also  a  collection  of  records  and 
relationships.  The  relationships  are  nianv-to-manv  instead  of  one-to-manv. 
Figure  3.8  shows  Complex  Network  Relationship. 

1.  Tree  or  hierarchical  relationships 

The  tree  which  is  illustrated  in  Figure  3.6  can  be  modeled  by  constructing  two 
relations  as  in  Figure  3.9. 

Relation  ML  contains  the  Name,  Mission,  Location  attributes,  and  relation 
PILOT  contains  the  Name  and  Pilot  attributes.  Name  is  primary  key  of  the  ML 
relation,  and  Name  and  Pilot  together  are  the  primary  key  of  the  PILOT  relation.  This 
relational  representation  is  useful  when  we  need  a  information  about  pilots  who  work 
in  specific  wing  or  squadron. 

2.  Simple  Network  Relationships 

Consider  the  undergraduate  education/squadron/pilots  relationship  as  it  is 
shown  in  Figure  3.7.  As  we  mentioned  earlier,  Figure  3.7  represents  a  simple  network 
relationship.  In  Figure  3.10,  the  following  relation  structure  will  represent  this 
network: 

EDUCATION  (  School,  Major,  Grad_year  ) 
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EDUCATION 


SQUADRON 


Air  Force 
Academy 


2nd  Air  Force 
Academy 


College 


B 


PILOTS 


Figure  3.7     Example  o[  Simple  Network.  Relationship. 
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CADT 

ISP 

ABC 

COURSE 
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Figure  3.8     Example  of  Complex  Network  Relationship. 
SQUADRON      (Name,    Num_piiot    ) 
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Name 


Mission  Location 


1st  AFB 

TFW 

Seoul 

2nd  AFB 

RFW 

Pus  an 

3rd  AFB 

ATW 

Taegu 

*  AFB:  Air  Force  Base 

*  TFW: Tactical  Fighter  Wing 

*  RFW: Rescue  Flying  Wing  ' 

*  ATW: Air  Trasf ortation  Wing 

a.  Mission  and  Location 
(ML)  relation 


Name 

Pilot 

1st  AFB 

Jae  B.  Park 

1st  AFB 

Jung  S.  Kim 

1st  AFB 

Dong  I.  Oh 

2nd  AFB 

Kil  D.  Hong 

2nd  AFB 

Jung  G.  Lee 

3rd  AFB 

Tae  S.  Jeong 

3rd  AFB 

Kyo  M.  Kang 

b.  PILOT  relation 


Figure  3.9     Relational  Representation  of  Tree  Relationship. 

PILOT     ( Mil_serv_num,  Name,  School,  Major,  Squadron  ) 

As  it  is  shown  in  Figure  3.10,  there  are  no  special  constructs  to  represent  the 
relationship. 

Instead,  relationships  can  be  determined  by  pairing  equal  values  of  attributes. 
These  relations  are  very  useful  when  we  need  some  information  about  pilots  who 
graduate  from  a  specific  school  and  study  specific  subjects.  For  example,  let's  assume 
that  we  want  to  know  how  many  pilots  work  with  Jae  B.  Park.  To  respond  to  this 
query,  we  can  find  PILOT  tuples  for  Jae  B.  Park.  Next,  we  can  find  the  number  of 
pilots  from  333rd  SQ  tuple  in  the  SQUADRON  relation. 
3.  Comple.x  Network  Relationships 

The  relational  model  representation  of  a  complex  relationship  is  similar  to 
that  of  simple  network  relationship.  Figure  3.11  is  based  on  Figure  3.S.  A 
straightfoward  way  of  representing  this  structure  is  to  define  three  relations:  one  for 
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EDUCATION  Relation 


School 


Major 


SQUADRON  Relation 


Name 

N_pilot 

333rd  SQ 

10 

505th  SQ 

50 

PILOT  Relation 


G_year 


AF  Academy 

Mechanical  Eng. 

1980 

2nd  AF  Academy 

0.  R 

1977 

Air  College 

Management 

1982 

MSN   Name 

School 

Major 

Squadron 

61543  Jar  Park 

AF  Academy 

Mechanical  Eng. 

333rd  SQ 

65320  Gil  Hong 

2nd  AF 
Academy 

O.R 

505th  SQ 

54252  Tae  Lee 

Air  College 

Management 

270th  SQ 

Figure  3.10     Relational  representation  of  Simple  Network  Relationships. 

pilots,  one  for  nulitary  training  courses,  and  one  for  the  relationship  between  pilots  and 
military  training  courses.  This  last  relation  is  an  intersection  record.  The  following 
relation  structure  will  represent  this  network: 

PILOTS  (    Mil_serv_num,    Name,    Rank    ) 
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MTC        (  Cour_name,  Year,  Num- student  ) 

PILOT_MTC  (  Mil_serv_num,  Ccur_name  ). 

It  is  very  easy  to  find  someone's  career  by  using  these  relations.  For  example, 
let's  consider  the  question  What  kinds  of  military  training  courses  has  Capt.  Jae  Park 
taken  so  far?".   According  to  Figure  3.11,  he  took  AGOC  and  CADT  course. 


MSN 


Name 


Rank 


61543 

Jae  Park 

Capt; 

65320 

Gil  Hong 

Capt 

54252 

Tae  Lee 

Col 

PILOTS    Relatiion 


MSN 


Cname   Year   No_Student 


AGOC 

83-7 

50 

ABC 

82-5 

60 

CADT 

83-8 

70 

ISP 

84-3 

80 

MTC(military  training 
course)  Relation 


Cname 


61543 

AGOC 

61543 

CADT 

65320 

CADT 

65320 

ISP 

54252 

ABC 

54252 

ISP 

PILOTS_MTC  Relation 


Figure  3.11     Relational  representation  of  Complex  Network  Relationship. 
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To  manipulate  data  in  the  database  by  the  application  program  we  need  a 
Data  Manipulation  Language  or  DML-  one  for  each  host  language.   The  DML  acts  as 
an  interface  language  with  the  database.   Its  major  functions  are 
to  select  a  record  from  the  database 
to  represent  it  to  the  application  program 
to  add  new  records  and  relationships  in  the  database 
to  change  existing  records  and  relationships  in  the  database 
to  remove  existing  records  and  relationships  from  the  database 
[Ref  8:  p.52]. 

As  it  is  discussed  in  Figure  3.11,  understanding  of  representations  of  three 
relationships  are  very  important  to  get  flexible  and  useful  information  in  a  personnel 
management  system.  Each  relationship  is  useful  for  individual  required  characteristic 
of  query.   An  example  is  shown  in  Figure  3.11. 

D.       DATA  MANIPULATION  LANGUAGES 

The  notation  for  expressing  queries  is  usually  the  most  significant  part  of  a  data 
manipulation  language.  The  nonquery  aspects  of  a  relational  data  manipulation 
language,  or  "query  language,"  are  often  straightfoward,  being  concerned  with  the 
insertion,  deletion  and  modification  of  the  tuples.  On  the  other  hand,  queries,  which  in 
the  most  general  case  are  arbitrary'  functions  applied  to  relations,  often  use  a  rich,  high 
level  language  for  their  expression. 

Query  languages  for  the  relational  model  break  down  into  two  broad  classes: 

(1)  Algebraic   languages,   where   queries   are   expressed   bv   applying   specialized 
operators  to  relations,  and 

(2)  Predicate  calculus  languages,  where  queries  describe  a  desired  set  of  tuples  by 
specifying  a  predicate  the  tuples  must  satisfy.   [Ref  6:  p.  104] 

1.  Relational  algebra 

Relational  algebra  operates  one  or  more  relations  and  produces  a  new  relation 

as  the  result.    The  operations  are  expressed  in  a  system  of  notation  and  they  can  be 

used  to  retrieve  information  from  one  or  more  relations  or  to  update  a  tuple  of  a 

relation.     We    shall   describe    here    six   operations    of  which   the    first    three-    union, 

intersection  and  difference  are  traditional  set  operations;  the  other  three  -  projection, 

join   and   division    -    are    less   common.     Relations    can   be   manipulated   using    the 

opertators   +,  -,  etc.,  in  high  school  algebra  to  achieve  a  desired  result.    Relation 

algebra  is  hard  to  use,  partly  because  it  is  procedural.    That  is,  when  using  relational 
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algebra  we  must  know  not  only  what  we  want,  but  also  how  lo  get  it.  In  high  school 
algebra,  variables  represented  numbers,  and  operations  like  -(-.-,  x  ,  and,'  operated  on 
numeric  quantities.  For  relational  algebra,  however,  the  variables  are  relations,  and  the 
operations  manipulate  relations  to  form  new  relations.  For  example,  the  operation  +  ( 
or  union  )  combines  the  tuples  of  one  relation  with  the  tuples  of  another  relation. 
[Ref  7:  p.255] 

a.  Union 

The  union  of  set  A  with  set  B,  denoted  as  A  U  B,  is  the  set  of  all  objects 
without  repetition.  We  only  apply  the  union  operator  to  relations  of  the  same  number 
of  attribute,  so  all  tuples  in  the  result  have  the  same  number  of  attribute.  Each 
attribute  should  have  same  domain.  This  can  be  used  to  insert  a  new  tuple  to  a 
relation. 

b.  Intersection 

The  intersection  of  set  a  with  set  B,  denoted  as  A  fl  B.  is  the  set  of  all 
objects  belonging  to  both  A  and  B.  So  the  intersection  oi^  two  relations  is  a  third 
relation  contammg  common  tuples.  Again,  the  relations  must  be  union  compatible. 
This  can  be  used  to  fmd  a  duplicate  tuple  between  two  relations. 

c.  Difference 

The  difference  of  set  b  from  set  a,  denoted  as  A  -  B.  is  the  set  of  all  objects 
belonging  to  A  but  not  to  B.  That  is,  the  difference  of  two  relations  is  a  third  relation 
containing  tuples  which  occur  in  the  first  relation  but  not  in  the  second.  The  relations 
must  be  union  compatible.  This  can  be  appUed  to  delete  a  tuple.  To  amend  a  tuple, 
we  must  first  delete  it  with  a  difference  operation  and  then  insert  the  amended  tuple  by 
a  union  operation. 

d.  Projection 

Projection  is  the  selection  of  one  or  more  named  domains  from  a  relation  in 
a  specified  order,  followed  by  the  ehmination  of  duplicate  tuples  from  the  resulting 
relation.  (  In  fact  in  all  operations  used  in  relational  algebra,  duplicate  tuples  are 
removed  since  they  are  not  allowed  in  a  relation.)  That  is,  the  result  of  the  projection 
is  a  new  relation  having  the  selected  attributes.  In  other  words,  projection  picks 
columns  out  of  a  relation.  Since  the  result  of  projection  is  a  relation,  and  since 
relations  can  not  contain  duplicate  tuples,  the  redundant  tuple  is  eliminated. 
Projection  can  also  be  used  to  change  the  order  of  attributes  in  a  relation.  We  shall 
use  the  notation  R  [  ABC  j  to  denote  the  projection  of  domains  A,  B  and  C  in  that 
order  from  relation  R. 
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e.   Join 

The  join  operation  is  a  combination  of  the  product,  and  projection 
operations.  The  join  of  relation  A  with  relation  B  produces  a  relation  R  that  consists 
of  all  the  possible  tuples  obtained  by  concatenating  each  tuple  of  A  with  all  tuples  of  B 
that  have  the  same  value  under  the  common  domain.  A  tuple  of  an  original  relation  is 
excluded  from  the  resultant  relation  if  its  value  under  the  common  domain  is  not 
shared  by  a  tuple  of  the  other  relation.  The  resultant  relation  contains  all  the  domams 
of  both  the  original  relations,  the  common  domain  appearing  only  once.  Let's  assume 
there  are  two  relations  A  (  SQUADRON  PILOT  )  and  B  (  PILOT  MTC  )  as  given 
below. 


A( SQUADRON 

PILOT) 

B(  PILOT 

MTC) 

255SQ      Jae 

B, 

Park 

Jae  B.  Park 

AGOC 

303SQ     Dong 

I. 

Lee 

Jae  B.  Park 

CADT 

506SQ    Jang 

K. 

Cho 

Jang  K.  Cho 

ISP 

355SQ      Jae 

S. 

Jeong 

Hwan  S.  Lee 

ABC 

Their  join  R  is 

R  (  SQUADRON 

PILOT           MTC  ) 

255SQ 

Jae  B. 

Park        AGOC 

255SQ 

Jae  B. 

Park        CADT 

506SQ 

Jang  K. 

Cho         ISP 

For  operational  convenience,  in  all  subsequent  join  operations,  we  shall 
assume  the  common  domain  to  be  the  rightmost  domain  of  the  first  relation  and  the 
leftmost  domain  of  the  second  relation  as  it  is  shown  above;  this  can  be  ensured  if 
necessar\'  by  a  suitable  projection  operation.  Join  in  conjunction  with  the  projection 
operation  provides  a  very  useful  tool  for  the  manipulation  of  relations. 
/.    Product 

The  product  of  two  relations  (  cartesian  product  )  is  the  concatenation  of 
ever>'  tuple  of  one  relation  with  every  tuple  of  a  second  relation.    The  product  of 
relation  A  (  having  m  tuples  )  and  relation  B  (  having  n  tuples  )  has  m  times  n  tuples. 
The  product  is  denoted  A  x  B  or  A  times  B.   [Ref  7:  p.257] 
g.   Division 

We  may  divide  a  binar\'  relation  by  a  unary  relation  if  the  domain  of  the 
unary  relation  is  also  a  domain  of  the  binarv'  relation.  The  result  of  such  a  division  is  a 
unary  relation  containing  the  uncommon  domain  of  the  binar>'  relation  is  selected  for 
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the  resultant  relation,  if  its  associated  entries  in  the  ccinmon  domain  contain  ail  the 
values  of  the  divisor  domain.  Consider  a  binary  relation  DT  and  three  unar>'  relations 
DI,  DJ  and  DK  as  given  below. 

DI    (P#)  DJ   (?#)  DK   (P#) 

PI  PI  PI 

P2  P2 

P3 


DT  ( 

s# 

P#  ) 

SI 

PI 

SI 

P2 

SI 

P3 

SI 

P4 

S2 

PI 

32 

P3 

S2 

P4 

S3 

PI 

S3 

P2 

Denoting  division  by  (slash)  and  the  resultant  relation  by  R,  we  have 

DT/DI=R(S#)  DT/DJ=R(S#)  DT/DK=R(S#) 

51  SI  SI 

52  S3 
S3 

For  operational  convenience  in  division,  as  in  join,  we  shall  assume  the 
rightmost  (that  is.  the  second)  domain  of  the  dividend  as  the  common  domain.  All 
algebraic  operations  will  be  evaluated  from  right  to  left  giving  precedent  to  projection 
operation  over  join  and  division,  the  priority  over  projection  being  indicated  by 
ordinary'  brackets(  ). 

Relational  algebra  can  be  used  for  a  procedural  language.  It  is  extremely 
powerful  and  is  device  independent,  since  the  queries  are  based  on  the  values  of  the 
data  Items  rather  than  their  positions.  However,  the  construction  of  an  algebraic 
expression  for  a  query  is  very  tedious,  even  though  the  technique  can  quickly  be  learnt. 
In  addition,  the  nature  of  a  query  is  not  obvious  from  the  algebraic  expression  unless  it 
is  patiently  worked  out.  These  tend  to  increase  the  chances  of  errors  in  the  queries. 
Relational  calculus  is  designed  to  improve  this  situation.  [Ref  8:  p.  150] 
2.  Relational  calculus 

Relational  calculus  is  one  of  the  strategies  for  manipulating  relations.  It  is  a 
nonprocedural  language  for  expressing  what  we  want  without  expressing  how  to  get  it. 
In    relational    algebra    the    user    specifies    the    detailed    procedures    for    extracting 
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information,  whereas  in  relational  calculus  the  user  defines  what  he  wants,  leaving  the 
system  to  work  out  the  procedure  required.  The  expression  of  a  relational  calculus  has 
two  parts,  a  target  list  which  consists  of  a  list  of  the  wanted  elements  separated  by 
commas,  and  a  logical  expression,  called  a  predicate  or  qualification,  which  defines  the 
wanted  elements  in  terms  of  the  relations  from  which  they  are  to  be  extracted.  It  is 
written  in  the  form 

Target   list   :    predicate 
to  be  interpreted  as:  extract  the  elements  in  the  target  list  such  that  (  or  where)  the 
predicate  is  true.   [Ref  8:  p.  152] 
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IV.  RELATIONAL  DATABASE  DESIGN 

A.       INTRODUCTION 

The  combination  of  DBMS  software,  applications  software,  database 
implementation,  and  operating  system/ hardware  environment  brought  together  to 
provide  information  services  for  users  is  known  as  a  database  system.  Although  the 
technology  for  DBMS,  operating  system,  and  applications  programming  is  well 
developed,  little  attention  has  been  given  to  the  effective  use  of  these  tolls  with 
alternative  database  structures.  Thus,  the  major  problem  facmg  the  database 
administrator  is  not  whether  to  use  this  technology,  but  how  to  use  it  effectively.  This 
problem  can  be  summarized  by  a  number  of  issues  that  arise  through  the  life  cycle  of 
an  application: 

(1)  What  are  the  user  requirements,  and  how  can  they  be  expressed? 

(2)  How  can  these  requirements  be  translated  into  an  effective  database  structure? 

(3)  When  should,  and  how  can,  the  database  structure  be  adapted  to  new  and/ or 
changing  requirements? 

The  process  of  developing  a  database  structure  from  user  requirements  is  called 
database  design.  Many  practitioners  have  argued  that  they  are  at  least  two  separate 
steps  in  the  database  design  process:  the  design  of  a  logical  database  structure  which  is 
processible  by  the  DBMS  and  describes  the  user's  view  of  the  data,  and  then  selection 
of  a  physical  structure  that  includes  data  representation  or  encoding,  access  methods, 
and  physical  clustering  of  data.  Other  than  the  logical/physical  delineation,  however. 
the  overall  structure  of  the  design  process  has  not  been  well  defmed,  and  even  the 
logical/ physical  boundary'  has  been  open  to  considerable  dispute.  We  wish  to  avoid 
this  confusion  by  defining  more  concisely  each  step  in  the  design  process. 

Database  design  is  an  intuitive  and  artistic  process.  There  is  no  algorithm  for  it. 
Typically,  database  design  is  an  iterative  process;  during  each  iteration,  the  goal  is  to 
get  closer  to  an  acceptable  design.  Thus  a  design  will  be  developed  and  then  reviewed. 
Defects  in  the  design  will  be  identified,  and  the  design  will  be  redone.  This  process  is 
repeated  until  the  development  team  and  users  can  find  no  major  defects.  ( 
Unfortunately,  this  does  not  mean  the  design  will  work;  it  simply  means  no  one  can 
think  of  any  reason  why  it  won't.) 
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'I  he  database  is  the  bridge  between  people  and  hardware.  As  mentioned  earlier, 
the  characteristics  of  both  people  and  hardware  need  to  be  considered.  Consequently, 
database  design  is  divided  into  two  phases:  logical  design,  where  the  needs  of  people 
are  specified,  and  physical  design,  where  the  logical  design  is  mapped  into  the 
constraints  of  particular  program  and  hardware  products.  Figure -4.1  illustrates  the 
flow  of  work  in  a  typical  database  design  project.  User  requirements  are  studied  and  a 
logical  database  design  is  developed.  Concurrently,  the  preliminary  design  of  database 
processing  programs  is  produced.  Next,  the  logical  database  and  the  preliminary 
program  designs  are  used  to  develop  the  physical  database  design  and  the  detailed 
program  specifications.  Finally,  both  of  these  are  input  to  the  implementation  phase 
of  the  project. 

This  chapter  will  introduce  theoreticallogical,  physical  database.  And  then  we 
will  discuss  about  relation  database  design  in  detail  and  hypothetical  Korean  Army  or 
Air  Forces  data  will  be  used  to  show  examples. 

Practical  sample  application  program  is  shown  in  Appendix  A. 
[Ref  7:  pp.  177,178] 
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Figure  4.1     Database  and  Program  Design  Flow  . 


'Kroenke,  David  M.,  Database  processing:  Fimdamenials,  Design,  Implementation, 
Science  Research  Associates  INC., 1983 
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B.       LOGICAL  DATABASE  DESIGN 

Conceptual  design  deals  "with  information  independent  of  any  actual 
implementation.  It  is  the  objective  of  conceptual  design  to  represent  information  in  a 
form  that  is  comprehensible  to  the  user  independent  of  system  specifies,  but 
implementable  on  several  systems. 

1.  Outputs  of  logical  database  design 

A  logical  database  design  specifies  the  logical  format  of  the  database.  The 
records  to  be  maintained,  their  contents,  and  relationships  among  those  records  are 
specified.  Industry  uses  various  terms  for  this  design.  It  is  sometimes  called  the 
schema,  the  conceptual  schema,  or  the  logical  schema.  We  will  use  the  term  logical 
schema  because  it  is  the  schema  developed  during  logical  design. 

a.  Logical  database  records 

To  specify  logical  records,  the  designer  must  determine  the  level  of  detail  of 
the  database  model.  If  the  model  is  highly  aggregated  and  generalized,  there  will  be 
few  records.  If  model  is  detailed,  there  will  be  many  records.  The  database  designer 
must  examine  the  requirements  to  determine  how  coarse  or  how  fine  the  database 
model  should  be.  The  contents  of  these  records  are  specified  during  logical  design. 
Figure  4.2  shows  an  example  of  field  description. 

b.  Logical  database  record  relationship 

The  essence  of  database  is  the  representation  of  record  relationships.  These 
relationships  are  specified  during  logical  design.  The  designer  studies  the  application 
environment,  examines  the  requirements,  and  identifies  necessary  relationships. 

Figure  4.3  shows  possible  relationships  for  several  records  in  military 
personnel  management  systems  database.  The  arrows  represent  many-to-many 
relationships  between  database  records.  Data  structure  diagrams  are  not  the  only  tool 
for  expressing  relationships.  To  summarize,  their  content,  constraints,  and 
relationships. 

2.  Inputs  to  logical  database  design 

The  inputs  to  logical  database  design  are  the  system  requirements  and  the 
project  plan.  Requirements  are  determined  by  interviews  with  users,  and  that  they  are 
approved  by  both  users  and  management.  The  project  plan  describes  the  system 
environment,  the  development  plan,  and  constraints  and  limitations  on  the  system 
design. 
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Field  Description 

PERSON  Record 

Rank  Alphabetic,  25  character 

Military_Serice_Number  Numeric,  15  decimal  degit 

Name  Alphabetic,  25  characters 

Address  Alphabetic,  70  characters 

MILITARY  CAREER  Record 

Military  Service  Number  Numeric,  15  decimal  degit 

Unit_name  Alphabetic,  20  characters 

Duty  _name  Alphabetic,  30  characters 

Duty_rank  Alphabetic,  25  characters 

Date  Format  :  YYMMDD 


Figure  4.2     Sample  field  description  for  PERSON  and  MILITARY  CAREER  records. 

The  requirement  will  be  expressed  in  the  form  of  data  flow  diagrams,  policy 
statements,  and  the  data  dictionar^^'.  Having  the  requirements  in  this  form  will  greatly 
facilitate  the  logical  design  process.  Contents  of  the  data  dictionary'  can  be 
transformed  into  the  logical  and  user's  views.  Policy  statements  can  be  used  to  develop 
the  descriptions  of  logical  database  processing.  The  requirements  can  be  used  to  verify 
the  completeness  of  the  logical  design.  If  the  requirements  are  defined  in  narrative 
style,  they  will  need  to  be  converted  to  a  format  that  facilitates  logical  database  design. 
3.  Procedures  for  logical  database  design 

The  major  steps  in  the  logical  design  process  are  described  below. 

(1)      Identify  data  to  be  stored.    The  data  dictionary'  is  processed  and  data  that  is 
to  be  stored  is  identified  and  segregated. 
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PERSON 


f 


v> 


PERSON 


■^ 


MILITARY  EDUCATION 


'/^ 


^^ 


MILITARY  CAREER 


Figure  4.3     Data  Structure  Diagram. 

(2)  Consolidate  and  clarifv  data  names.  One  task  is  to  identify  synonyms,  to 
decide  on  standard  names  (or  svnonyms,  and  to  record  aliases.'  Svnonvnis  are 
two  or  more  names  for  the  same  data  item. 

(3)  Develop  the  logical  schema.  The  third  step  in  the  design  process  is  to  develop 
the  logical  sciiema  bv  delininc  records  and  relationships.  Records  are  dciined 
by  deternuning  the  data  items~they  will  contain. 

(4)  Define  processing.  The  requirements  are  examined  to  determine  how  the 
database  should  be  manipulated  to  produce  required  results.  The  processing 
defines    can    be    developed    in    several    wavs.     One    method    is    to    describe 

/  transactions    and    data    to    be    modified.   'Another    method    for    describing 

database  processing  is  to  develop  structure  charts  of  the  programs  that  will 
access  the  database.  One  method  for  developing  such  processiiig  descriptions 
is  called  transform  analysis. 

(5)  Design  review.  The  logical  schema  and  user  views  are  examined  in  light  of  the 
requrrements  and  program  descriotions.  Everv  attempt  is  made  to  identify 
omissions,  unworkable-aspects,  or  "the  flaws  in  the  design.   [Ref  7:  p.  181 J 

C.       PHYSICAL  DATABASE  DESIGN 

The  second  stage  of  database  design  -  physical  design  -  is  a  stage  of 
transformation.  The  logical  schema  is  transformed  into  the  particular  data  constructs 
that  are  available  with  the  DBMS  to  be  used.  Whereas  the  logical  design  is  DBMS  - 
independent,  the  physical  design  is  very  much  DBMS  -  dependent. 

1.  Outputs  of  physical  database  design 

Specific  constructs  vary  widely  from  one  DBMS  to  another.  At  this  point,  we 
can  not  be  very  detailed.  In  general,  two  major  specifications  are  produced.  First,  the 
physical  specification  of  the  logical  schema  is  defined.  We  will  call  this  specification 
the  physical  schema.  This  schema  is  transformation  of  the  logical  schema  into  the  data 
modeling  constructs  available  with  the  DBMS  to  be  used.  Second,  user  views  are 
defined. 
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PHYSICAL  SCHEMA.  The  content  of  each  record  must  be  defined,  and  the 
name  and  format  of  each  field  of  each  record  specified.  Constraints  from  the  logical 
database  design  are  transformed  into  criteria  for  field  descriptions.  Keys  of  database 
records  need  to  be  identified,  and  overhead  structures  for  supporting  the  keys  defined. 
For  example,  the  designer  may  specify  that  a  particular  key  is  to  be  supported  by  an 
inverted  list.  Record  relationships  are  also  defined  in  the  physical  design.  Limitations 
in  the  DBMS  may  necessitate  that  record  relationships  be  changed  from  what  the  users 
wanted.  A  many-to-many  relationship  may  need  to  be  changed  to  a  simple  network, 
for  example. 

USER  VIEWS.  The  second  component  of  a  physical  database  design  is  the 
user  views.  Since  most  users  w\\\  need  to  view  only  a  portion  of  the  database,  the 
logical  design  must  specify  which  user  groups  will  view  which  portions  of  the  database. 

User  views  are  generally  a  subset  of  the  schema.  Records  or  relationships  may 
be  omitted  from  a  view;  fields  may  be  omitted  or  rearranged.  ■  Also,  the  names  of 
records,  fields,  or  relationships  may  be  changed.  This  flexibility  allows  uers  to  employ 
terminology  that  is  familiar  and  useful  to  them.   [Ref.  7:  pp.  188.189] 

2.  Inputs  to  logical  database 

The  inputs  to  the  physical  database  design  are  the  outputs  of  the  logical 
database  design,  the  system  requirements,  and  the  preliminary  design  of  programs. 

3.  Physical  design  steps 

The  physical  design  phase  can  also  be  categorized  into  distinct  steps  based  on 
groups  of  related  design  decisions.  However,  once  again,  the  proper  ordering  of  these 
steps  is  open  to  conjecture,  owing  to  the  fairly  strong  dependencies  between  these 
groups  of  design  decisions.  Practical  experience  has  shown  that  neither  the  starting 
point  nor  the  order  of  steps  can  be  definitely  stated  for  a  given  design  problem.  On  the 
other  hand,  the  physical  design  phase  can  be  regarded  as  an  iterative  process  of  initial 
design  and  refinement.  Each  of  proposed  steps  needs  to  be  performed  several  times, 
but  each  succeeding  analysis  should  be  done  more  quickly  because  the  procedure  is 
known  and  the  number  of  unchanging  performance  variables  should  be  increasing 
between  iterations.  Typically,  two  or  three  passes  through  the  substeps  will  result  in 
convergence  to  a  solution.  The  relative  importance  of  each  step  toward  system 
performance  becomes  obvious  through  experience  and  careful  documentation  of  the 
entire  analysis. 
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The  foilow.iig  fr^e  steps  include  three  that  represent  the  major  categories  of 
physical  database  structure  design  and  two  that  involve  constraints  and  program 
design. 

STEP  1:  STORED  RECORD  FORMAT  DESIGN.  Assuming  that  the 
logical  record  structure  has  been  defined,  this  process  addresses  the  problem  of 
formatting  stored  data  by  analysis  of  the  characteristics  of  data  item  types,  distribution 
of  their  values,  and  their  usage  by  various  applications.  Decisions  on  redundancy  of 
data,  derived  versus  explicitly  stored  values  of  data,and  data  compression  are  made 
here. 

Certain  data  items  are  often  accessed  far  more  frequently  than  others,  but 
each  time  a  particular  piece  of  data  is  needed,  the  entire  stored  record,  and  all  stored 
records  in  physical  block  as  well,  must  be  accessed.  Record  partitioning  defines  an 
allocation  of  individual  data  items  to  separate  physical  devices  of  the  same  or  different 
type,  or  separate  extents  on  the  same-device,  so  that- total  cost  of  acces-sing  data  for  a 
given  set  of  user  applications  is  minimized.  Logically,  data  items  related  to  a  single 
entity  are  still  considered  to  be  connected,  and  physically  they  can  still  be  retrieved 
together  when  necessary.  An  extent  is  a  contiguous  area  of  physical  storage  on  a 
particular  device. 

STEP  2:  STORED  RECORD  CLUSTERING.  One  of  the  most  important 
physical  design  considerations  is  the  physical  allocation  of  stored  records,  as  a  whole. 
to  physical  extents.  Record  clustering  refers  to  the  allocation  of  records  of  different 
types  into  physical  clusters  to  take  advantage  of  physical  sequentiality  whenever 
possible.  Analysis  of  record  must  take  access  path  configuration  into  account  to  avoid 
access-lime  degradation  due  to  new  placement  of  records. 

Associated  with  both  record  clustering  and  record  partitioning  is  the  selection 
of  physical  block  size.  Blocks  in  a  given  clustered  extent  are  influenced  somewhat  by 
stored  record  size,  but  also  by  storage  characteristics  of  the  physical  devices. 
Furthermore,  larger  blocks  are  typically  associated  with  sequential  processing  and 
smaller  blocks  with  random  processing.  Thus,  we  see  that  although  block  size  is 
closely  related  to  clustering,  it  is  also  dependent  on  access  path,  type  of  applications, 
and  hardware  characteristics.  Consequently,  choice  of  block  size  may  be  subject  to 
considerable  revision  during  an  iterative  design  process. 

STEP  3:  ACCESS  METHOD  DESIGN.  An  access  method  provides  storage 
and  retrieval  capabilities  for  data  stored  on  physical  devices,  usually  secondary  storage. 
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The  two  critical  components  of  an  access  method  are  storage  structure  and  search 
mechanisms.  Storage  stmcture  defines  the  limits  of  possible  access  paths  through 
indexes  and  stored  records,  and  the  search  mechanisms  define  which  paths  are  to  be 
taken  for  given  applications.  Intrarecord  design  and  device  allocation  aspects  of 
storage  structure  are  not  used  here,  whereas  index  design  and  interrecord  connections 
are  quite  relevant. 

An  attribute  is  an  item  type  it  may  be  used  as  a  primary  key,  secondary  key, 
or  nonkey.  A  primary  key  uniquely  defines  a  record.  A  secondary  key  is  an  attribute 
used  as  an  index  to  records,  but  it  does  not  uniquely  identify  those  records.  A  nonkey 
is  an  attribute  that  is  not  used  as  a  primar\'  or  secondary  key  for  indexing  or  other 
search  mechanism  for  records. 

Access  method  design  is  often  defined  in  terms  of  primary  and  secondary 
access  path  structure.  The  primary  access  paths  are  associated  with  initial  record 
loading,  or  placement,  and  usually  involve  retrieval  via  the  primary  key.  Individual 
files  are  first  designed  in  this  manner  to  process  the  dominant  application  most 
efficiently.  For  the  same  reason,  physical  databases  may  require  several  primary  access 
paths.  Secondary  access  paths  include  interfile  linkages  and  alternate  entr\'-point 
access  to  stored  records  via  indexes  on  secondary  keys.  Access  time  can  be  greatly 
reduced  through  secondary  indexes,  but  at  the  expense  of  increased  storage  space 
overhead  and  index  maintenance.   Step  1  -  3  are  controlled  by  our  DBMS. 

STEP  4:  INTEGRITY  AND  SECURITY  CONSIDERATIONS.  As  in 
implementation  design,  trade-olTs  among  integrity,  security,  and  efficiency  requirements 
must  be  analyzed. 

STEP  5:  PROGRAM  DESIGN.  The  goal  of  physical  data  independence,  if 
met.  precludes  application  program  modifications  due  to  physical  structure  design 
decisions.  Standard  DBVIS  routines  should  be  used  for  all  accessing,  and  query  or 
update  transaction  optimization  should  be  performed  at  the  systems  software  level. 
Consequently,  application  program  design  should  be  completed  when  the  logical 
database  structure  is  known.  When  physical  data  independence  is  not  guaranteed, 
program  modification  is  likely.  For  example,  a  program  based  on  a  navigational  access 
method  would  have  to  be  radically  changed  if  entr>'-point  access  methods  were 
introduced  for  the  first  time  during  the  physical  database  design  phase. 

Design  decisions  are  also  required  in  other  areas,  many  of  which  are  quite 
system  dependent.    Some  examples  are  selection  of  butfer  pool  size,  redundancy  of 
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stored  records,  and  differential  files.  These  issues  appear  to  be  equally  important  and 
difficult  to  analyze  for  both  physical  database  structure  and  file  design. 
[Ref  9:  pp.  169, 170] 

D.       NORMALISATION 

1.  Introduction 

By  now  we  have  examined  several  aspects  of  database  systems  in  general  and 
relational  systems  in  particular.  But  we  have  not  yet  considered  a  very  fundamental 
question,  namely:  Given  a  body  of  data  to  be  represented  in  a  database,  how  do  we 
decide  on  a  suitable  logical  structure  for  that  data?  In  other  words,  how  do  we  decide 
what  relations  are  needed  and  what  their  attributes  should  be?  This  is  the  database 
design  problem.  The  topic  of  this  section,  normalisation  theory,  is  basically  a 
formalisation  of  simple  ideas  such  as  this  one—a  formalisation  that  has  practical 
application  in  the  area  of  database  design. 

Before  going  any  further,  we  should  stress  the  fact  that  designing  a  database 
can  be  an  extremely  complex  task.  Normalisation  theory  is  a  useful  aid  in  design 
process,  but  it  is  not  a  panacea.  Anyone  designing  a  relational  database  is  advised  to 
be  familiar  with  the  basic  techniques  of  normalisation  as  described  in  this  section,  but 
we  certainly  do  not  suggest  that  the  design  should  be  based  on  normalisation  principles 
alone. 

2.  Functional  dependence 

A  functional  dependency  is  a  relationship  between  attributes.  Attribute  Y  is 
said  to  be  functionally  dependent  on  attribute  X  if  the  value  of  X  determines  the  value 
of  y.  Another  way  of  saying  this  is  that  if  we  know  the  value  of  X,  we  can  determine 
the  value  of  Y. 

For  example,  as  it  is  shown  in  Figure  4.4,  attnbutes  NAME  and  BIRTH  of 
relation  BASIC  are  each  functionally  dependent  on  attribute  MSN  because,  given  a 
particular  value  for  VI SN,  there  exists  precisely  one  corresponding  value  for  each  of 
NAME,  BIRTH  and  RANK.    In  symbols,  we  have 

PERSON.  MSN  -♦  PERSON.  NAME 

PERSON,  MSN  ->  PERSON.  BIRTH 

PERSON.  MSN  -»  PERSON.  RANK 

PERSON. MSN  ->  PERSON.  SPECIALTY 
or,  more  succinctly 

PERSON. MSN  -^    PERSON. (NAME, BIRTH, RANK, SPECIALTY) 
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PERSON( MSN, Name, Birth) 
key   :  MSN 


MSN 

NAME 

BIRTH 

RANK 

SPECIALTY 

166753 

Jae  Park 

85.  3.23 

Capt. 

pilot 

166720 

Sin  Yang 

85. 6. 12 

Capt. 

supply 

166542 

Jung  Kim 

85.2.  20 

Maj. 

security 

ASSIGNMENT( Name, Uni t, Posit ion, S_date) 
key  :  UNIT,  POSITION 


NAME 

UNIT 

POSITION 

START.DATE 

Jae  Park 

555SQ 

SQ  commander 

86.  10.  1 

Sam  Kim 

554SQ 

Intelligence  officer 

86.5.4 

Gun  Hong 

553SQ 

Operation  officer 

85.  12.23 

FAMILY( MSN , S_Name , S_S  SN , NOD ) 
key  :  MSN 


MSN 

SPOUSE  NAME 

SPOUSE  SSN 

NO  OF 
DEPENDENT 

166753 

Kyung  Bang 

1111-222 

3 

166720 

Eun  Park 

2222-333 

4 

166542 

Mi  Chun 

3333-444 

2 

Figure  4.4     Relational  view. 
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The  statement  "PERSON. MSN  ->  PERSON.NAME"  is  read  as  "attribute 
PERSON.NAME  is  functionally  dependent  on  attribute  BASIC.MSN",  or, 
equivalently,  "attribute  PERSON.  MSN  functionally  determines  attribute 
PERSON.NAME".  We  also  introduce  the  concept  of  full  functional  dependence. 
Attribute  Y  is  fully  functionally  dependent  on  attribute  X  if  it  is  functionally  dependent 
on  X  and  not  functionally  dependent  on  any  proper  subset  of  X.  For  example,  in  the 
relation  FAMILY,  the  attribute  NOD  is  functionally  dependent  on  the  composite 
attribute  (  MSN,  SPOUSE  NAME  );  however,  it  is  not  fully  functionally  dependent  on 
this  composite  attribute  because,  of  course,  it  is  also  functionally  dependent  on  MSN 
alone. 

On  the  other  hand,  attribute  NOD  is  fully  functionally  dependent  on  the 
composite  attribute  {  MSN,  S_SSN  ). 

The  objectives  of  normalisation  are: 
•  •      to  make  it  feasible  to  represent  any  relation  in  the  database 

•  to    obtain   powerful    retrieval    algorithms    based    on    a    simpler   collection    of 
relational  operations  than  would  otherwise  be  necessary' 

•  to  free  relations  from  undesirable  insertion,  update,  and  deletion  dependencies 

•  to  reduce  the  need  for  restructuring  the  relations  as  new  tvpes  of  data  are 
introduced 

•  to  make  the  collection  of  relations  neutral  to  the  querv-  statistics,  where  these 
statistics  are  liable  to  change  as  time  goes  by. 

[Ref.  10:  p.47] 

3.  Normal  form 

Normalisation  theory  is  built  around  the  concept  of  normal  forms.  A  relation 
is  said  to  be  in  a  particular  normal  form  if  it  is  satisfies  a  certain  specified  set  of 
constraints.  The  real  world  with  entities  and  their  properties  displays  a  multitude  of 
entity  relationships  which  can  be  expressed  in  the  form  of  two-dimensional  tables  or 
relations.  These  relations  will  in  general  be  unnormalised,  that  is,  they  may  contain 
repeating  groups  whose  presence  creates  serious  access  problems  leading  to  reduction 
in  data  independence.  A  relation  may  also  contain  nonprime  attributes  with  partial 
and  indirect  dependence  on  the  candidate  keys.  These  undesirable  associations  are 
removed  from  a  relation  by  normalisation  can  be  defined  as  a  step-by-step  reversible 
process  for  transforming  an  unnormaUsed  relation  into  relations  of  progressively 
simpler  structures.  Since  the  process  is  reversible,  no  information  is  lost  during  the 
transformation.    Codd  has  defined  three  stages  of  normalisation  known  as  the  first 
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MSN 


>   BIRTH 


UNIT 


POSITION 


MSN 


SPOUSE  SSN 


NAME 


RANK 


SPECILTY 


NAME 


S  DATE 


SPOUSE  NAME 


:>   NO  OF  DEPENDENT 


Figure  4.5     Functional  dependencies  in  relation  PFRSON.ASSIGNMENT, FAMILY. 
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(INF),  second  (2NF),  and  third  {3NF)  normal  forms  corresponding  to  the  three  types 
of  undesirable  association  discussed  above,  namely,  the  eleniination  of  the  repeating 
groups,  partial  dependence  and  indirect  dependence.  The  levels  of  normalisation 'are 
shown  in  Figure  4.6.   [Ref  8:  p.  1 35] 


Unnormalized  relation 


Remove  repeating  groups 
\1^ 


First  normal  form 


^ 


Remove  partial  dependence 


^^ 


Second  normal  form 
(  2  NF  ) 


Remove  indirect  dependence 


Third  normal  form 
(  3  NF  ) 


Figure  4.6    Three  levels  of  normalisation. 

a.    First  normal  form 

First  normal  form  is  the  starting  point,  that  is,  all  relations  are  in  first 
normal  form.  An  unnormalised  relation  is  transformed  into  INF  by  splitting  the 
relation  into  two,  one  for  the  repeating  groups  and  the  other  for  the  rest.  Consider  the 
relation  CAREER. 
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CAREERC  MSN , RANK , NAME , UNIT , JOB 

.LOCATION, S_DATE, 

E_DATE ) 

1111  Capt.   Jae  Park   222SQ 

A 

Kl 

83.4.1 

83.10.21 

223SQ 

B 

K2 

83.  10.22 

84. 11. 18 

2222  Lt/col.Sam  Kim    225SQ 

C 

K3 

84.  8.4 

85.7.  15 

226SQ 

D 

K4 

85.7.  16 

86. 8. 5 

Figure  4.7     An  unnormalised  relation  with  repeating  group. 

In  order  to  select  a  specific  person  who  is  most  proper  for  a  specific 
position  (or  job),  his/her  career  is  very  important.  In  that  case,  unnormalisation  can 
be  made  easily  as  it  is  shown  in  Figure  4.7.  This  clearly  unnormalised  relation, 'since  it 
includes  the  repeating  groups  of  item  code.  This  relation  is  transformed  into  tirst 
normal  form  by  splitting  it  into  two  relations  PERSON  and  JOB  as  it  is  shown  in 
Figure  4.8 

b.  Second  normal  form 

As  it  is  shown  in  Figure  4.6,  partial  dependence  is  removed  from  INF  in 
2NF.  The  second  normal  form  is  formally  defined  in  terms  of  what  is  called  functional 
dependence.  A  normalised  relation  is  said  to  be  in  the  second  normal  form  if  all  its 
nonprime  attributes  are  fully  dependent  on  each  candidate  key,  in  other  words,  if  non 
prime  attributes  do  not  show  any  partial  dependence  on  the  candidate  keys.  In  Figure 
4.7,  the  attribute  JOB  is  fully  functional  dependence  on  the  collection  of  domain  (MSN 
+  UNIT).  But  the  LOCATION  is  independent  of  the  MSN  and  is  therefore  only 
partially  dependent  on  the  key  (MSN  +  UNIT).  Finally  the  2NF  is  shown  in  Figure 
4.9. 

c.  Third  normal  form 

As  it  is  shown  in  Figure  4.6,  indirect  dependence  is  removed  from  2NF  in 
3NF.  A  normalised  relation  is  said  to  be  in  third  normal  form  if  all  its  nonprime 
attributes  are  fully  functionally  and  directly  dependent  on  each  candidate  key.  To 
demonstrate  transitive  dependence. 
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. 

PERSON(MSN,  RANK, 

NAME ) 

• 

1111  Capt. 

Jae  Park 

• 

2222  Lt/col 

Sam  Kim 

■ 

R1(MSN,  UNIT,  JOB, 

LOCATION,  S_DATE, 

E_DATE ) 

1111     222SQ 

A    Kl    83.4.1 

83.  10.21 

1111     223SQ 

B   K2    83.10.22 

84. 11. 18 

2222     225SQ 

C   K3    84.8.4 

85.7.  15 

2222     226SQ 

D    K4    85.7.16 

86.8.5 

'  Figure  4.8     Relations  in  INF  of  Figure  4.7. 

Let  us  consider  relation  MEMBER  (Figure  4.  I0)containing  Squadron. 
Pilot_nanie(P_NAME),  Quantity  of  squadron(QOS),  Rank.  If  SQ  is  the  candidate  key 
then  this  relation  is  not  in  3NF,  since  the  nonpriine  attributes  RANK  is  not  directly 
dependent  on  SQ.  They  are  dependent  on  P_NAME,  which  is  dependent  on  SQ.  We 
convert  this  into  third  normal  form  by  splitting  as  shown  in  Figure  4.1 1. 

Transitive  dependence  causes  update  problems  similar  to  those  caused  by 
partial  dependence.  Therefore  all  relations  must  be  expressed  in  3NF.  On  optimal 
third  normal  form  is  defined  as  the  minimum  number  of  relations  that  can  express  the 
original  unnormalised  relation. 

d.    Fourth  ami  fifth  normal  form 

Fourth  and  fifth  normal  forms  deal  with  multivalued  facts.  A  multivalued 
fact  may  correspond  to  a  many  to  many  relationship  or  to  a  many-to-one  relationship. 
Under  fourth  normal  form,  a  record  type  should  not  contain  two  or  more  independent 
multivalued  facts  about  an  entity.  In  addition,  the  record  must  satisfy  third  normal 
form.    Fifth  normal  (brm  deals  with  cases  where  information  can  be  reconstructed  from 
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• 

PERSON(MSN,  RANK,  NAME) 

1111   Capt. 

Jae  Park 

- 

2222   Lt/col. 

Sam  Kim 

/ 

R1(MSN,  UNIT, JOB,  S. 

.DATE,  E.DATE) 

1111 

222SQ   A 

83.4.  1 

83. 

10.21 

1111 

223SQ   B 

83.  10.22 

84. 

11.  18 

2222 

225SQ   C 

84.8.4 

85. 

7.  15 

2222 

226SQ   D 

85.  7. 16 

86. 

8.  5 

R2(UNIT, 

LOCATION) 

222SQ 

Kl 

223SQ 

K2 

225SQ 

K3 

226SQ 

K4 

Figure  4.9     Relations  in  2NF  of  Figure  4.7. 

smaller  pieces  of  information  which  can  be  maintained  with  less  redundancy.  Roughly 
speaking,  we  may  say  that  a  record  type  is  in  fifth  normal  form  when  its  information 
content  can  not  be  reconstructed  from  several  smaller  record  types,  i.e.,  from  record 
types  each  having  fewer  fields  than  the  original  record.  Fifth  normal  form  does  not 
dilTer  from  fourth  normal  form  unless  there  exists  a  symmetric  constraint.  One 
advantage  of  fifth  normal  form  is  that  certain  redundancies  can  be  eliminated. 

We  discuss  two  additional  normal  forms  very  briefiy  here,  in  order  to  give 
some  idea  as  to  how  normalisation  research  is  continuing. 
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MEMBER(SQ,  P_NAME ,  QOS, 

RANK) 

r 

222SQ   Jae  Park 

50 

Capt. 

* 

223SQ    Sam  Kim 

60 

Maj. 

• 

224SQ   Won  Hong 

70 

Maj. 

Figure  4.10    A  relation  showing  transitive  dependence. 


MEMBERK  SQ 

■  ■ 

,  P_NAME,  QOS) 

MEMBER2(SQ, 

P_NAME,  RANK) 

222SQ 

Jae  Park   50   - 

222SQ 

Jae  Park  Capt. 

223SQ 

Sam  Kim    60 

223SQ 

Sam  Kim   Maj 

224S0 

Won  Hong   70 

224SQ 

Won  Hong   Maj. 

Figure  4. 11     The  relations  of  Figure  4.10  in  3NF. 

E.       SCHEMA  DESIGN 
1.  View  of  the  schema 

A  relational  database  is  specified  by  a  relational  schema  which  consists  of  one 
or  more  relational  subschemas.  A  relational  subschema  is  a  listing  of  a  relation  name 
and  its  corresponding  attributes.  Figure  4.12  represents  an  example  of  a  relational 
schema. 

These  views  arc  then  integrated  to  form  an  enterprise  description  which 
describes  the  entire  conceptual  schema.  This  description  is  used  mainly  for 
communication  between  the  users  and  the  schema  designers.  For  each  entity  type 
identified,  a  description  of  the  entity  type  is  produced  and  the  associated  data  classes 
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PERSON(MSN,  Name 

I,  Rank, 

Birth) 

1 

key  :  MSN 

REWARD / PUNI SHMENT ( MSN , 

A_rank, 

Type, 

Data, 

Reason) 

key  ;  MSN  * 

Type  + 

Date 

MT(MSN,  C_name, 

S_date 

,  E_date, 

Period,  Grade) 

KEY  :  MSN  + 

C_name 

+  S_date 

*    E_ 

.date 

*  MT:  MILITARY 

TRAINING 

Figure  4.12     An  example  of  a  relational  schema. 

identified.    The  description  names  the  entity  type,  defmes  what  it  represents,  and  lists 
its  associated  attributes. 

2.  Identifying  constraints 

In  order  to  complete  the  enterprise  description  step,  identify  constraints  on  the, 
attributes,  entity  types,  and  relationship  types.    It  seems  better  to  state  all  constraints 
explicitly    rather   than    as    inherent    constraints.     To    help    identify   constraints,    the 
following  questions  are  posed: 

(1)  what  is  the  domain  of  values  for  each  attribute? 

(2)  What  are  the  known  functional  dependencies  between  attributes  of  each  entity 
type?  (it  is  discussed  in  detail  in  previous  section) 

(3)  What  are  the  keys  for  each  entity  type?  (it  is  discussed  in  detail  Chapter  III) 

(4)  What  are  the  predicate  constraints  to  be  placed  upon  the  data? 

It  is  dilficult  to  arrive  at  a  set  of  constraints  that  represents  the  application 
and  its  consistent  and  feasible,  because  some  forms  of  the  constraints  are  diflicult 
understand  and  are  prone  to  misunderstandings  and  errors.  Figure  -;.13  shows  domains 
and  attribute/domain  correspondence  based  on  Figure  4.12. 

F.       TRANSACTION  CONSIDERATION 

The  final   phase    of  the   enterprise   description    step    identifies    the    transaction- 
processing  requirements  of  the  organization  with  respect  to  the  enterprise  description. 
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Domain  Name 

Format  and  Meaning 

MSN 

positive  integer  less  than  10000 

Name 

char(20) ;full  names  of  person 

Rank 

char( 20) ;person's  rank 

Birth 

numeric  YYMMDD 

A_rank 

char( 20) ;person* s  rank  when  he/she 

was  Rewarded  or  punished 

C_name 

char(  40) '.military  training  course  name 

Grade 

value  is  'A' ,'B' ,'C' ,or  'D' 

Figure  4.13     An  example  of  domains  and  attribute/domain  correspondence  for  Fig  4.12. 

All  current  and  projected  transactions  are  included.  For  each  transaction,  the  designer 
identifies  its  nature  (retrieval,  update,  delete,  insert),  its  frequency,  its  origin 
(organizational  area),  and  its  purpose,  together  with  the  point(s)  of  schema  it  aOects. 
Figure  4.14  shows  a  example  of  transactions.  To  help  identify  requirements  for 
supporting  transactions,  the  following  questions  are  posed:  What  transactions  are 
required  by  each  organizational  area?  What  kind  of  access  is  required  by  each 
transaction?  What  reports  are  needed?  What  entity  types,  attributes,  and  relationship 
types  are  involved  in  each  transaction?  etc. 
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Transaction:  List  all  combat  pilots  who  have' some 

flying  qualification,  capability  grade, 
and  whose  rank  is  captain. 
Organizational  area:  Operational  Department 
Ent ity: PERSON( MSN , RANK , NAME ) 

COMBAT  QUALITY/ TRAINING( MSN , UNIT , FLY_Q , C_GRADE ) 
Relationship  types:  PERSON- COMBAT  QUALITY/ TRAINING 

1.  Retrieve  PERSON  entity(for  MSN,  RANK,  NAME) 

2.  P.etrieve  all  PERSON  entities  related  to  the 
COMBAT  QUALITY /TRAINING  via  a  PERSON- 
COMBAT  QUALITY/ TRAINING 


Figure  4.14    A  simple  example  of  transaction. 
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V.  SYSTEM  ANALYSIS  FOR  RELATIONAL  DESIGN 

A.       PROBLEMS  AND  USER'S  REQUIREMENT 

First  of  all,m  order  to  design  a  database,  we  should  interview  with  user  and  and 
decide  output  which  they  need.  In  case  of  the  R.O.K  Air  Force,  we  should  classify  or 
break  down  pilots  by  their  skill,ilying  hours,  flying  qualification  etc.  to  select  pilots 
who  are  best  for  specific  jobs.  This  step  consist  of  a  high-level  analysis  of  the  function 
of  an  organization.  Desired  inibrmation  of  personnel  managers,  or  unit  commanders 
might  include: 

1.  List  of  all  new  commissioned  officers  in  a  specific  year  concemine  scholarship, 
major,  health  condition,  family  condition,  etc. 

2.  The  number  of  cadets  or  candidates  who  should  be  commissioned  in  the  next 
year  or  at  a  specified  year  for  each  source  organization. 

3.  List  all  officers  with  each  rank  who  graduated  each  military  education  course. 

4.  Selection  of  some  officers  tor  some  positions. 

5.  Summary  of  an  officers  career  from  a  certain  previous  rank  up  to  the  current 
rank. 

6.  List  certain  officer's  rewards  or  punishments. 

7.  Present  an  information  list  for  promotion  purposes  for  each  rank  and  service 
branch,  including  career,  result  of  fltnees  reports,  education,  rewards  and 
punishment,  health  condition,  and  the  order  of  promotion  recommendation. etc. 

8.  List  all  pilots  who  satisfv  a  certain  level  of  flying  hours,  flying  qualification  and 
a  certain  type  of  aircraft' 

All  of  information  which  may  be  required  by  personnel  managers  can  not  be 

desired,  because  different  managers  request  different  information.    Personnel  managers 

might  need  information  for  their  job  in  addition  to  that  described  above.   The  purpose 

of  requirement  analysis  is  to: 

(1)  Gain  familiarity  with  the  area  of  the  organization  to  be  modeled 

(2)  Determine  the  information  requirements  of  the  orsanization  without  regard  to 
constraints  other  than  the  way  in  which  the  organization  does  business." 

(3)  Represent  these  requirements  via  some  formal  modeling  technique. 

Some  major  personnel  management  aspects  of  the  Republic  of  Korea  Army  are 
promotion  selection,  job  assignment  management,  estimation  of  required  personnel 
resources  for  education.  Welfare- Morale  management  and  payroll.  We  will  consider 
and  discuss  only  the  data  concerning  the  Personal  Record,  which  is  composed  of  basic 
information,  education,  career,  etc.  Record  relationships  and  record  structure  will  be 
discussed  in  detail  in  the  next  section. 
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Promotion  Selection  is  managed  by  the  Department  of  Personnel  Management. 
To  collect  the  general  personnel  data  for  promotion  selection,  2  to  10  oflicers  from 
each  branch  of  the  Army  execute  the  routine  job  of  manual  data  collection  ever>'  year. 
Since  it  is  a  manual  job,  there  exists  the  possibility  ofmistak.es  and  it  is  impossible  to 
provide  the  various  kinds  of  data  necessary  to  support  promotion  selection. 

In  the  case  of  assignment  management,  it  is  difficult  to  examine  the  data  for 
matching  required  personnel  with  available  personnel  resources  for  a  specific  job  or 
position.  Therefore,  an  officer  may  be  assigned  to  an  undesired  unit  or  job  because  of 
a  subjective  decision  made  by  the  detailing  officer.  This  has  caused  a  great  deal  ot^ 
personnel  dissatisfaction  with  job  assignments. 

The  Department  of  Personnel  Management  is  responsible  for  promotion  selection 
and  job  assignment  management.  The  Central  Financial  Corp  is  responsible  for 
payroll.  Welfare  management  is  the  responsibility  of  the  Welfare- Morale  Corps. 
Because  they  maintain  separate  data,  data  integrity  and  accuracy  is  ver\'  low. 

As  was  mentioned  above,  the  numerous  problems  faced  are  : 

(1)  Wasting  manpower  and  time  due  to  manual  processing  causing  work  delays 

(2)  Ineffectiveness  of  work  and  non-intesrated  data  processine  due  to  individual 
software  maintenance,  and  spending  a  relatively  laree  amount  of  time  on  the 
maintenance  effort  and  minor  enharicements 

(3)  Lack  of  proper  supporting  system  for  decision-making 

(4)  Lack  of  data  accuracy 

Figure  5.1  shows  the  scope  and  objectives  of  the  database  that  we  have  designed  in  this 
thesis. 

B.       MODELING 

The  essence  of  database  design  is  the  representation  of  record  relationships.  The 
relationships  can  be  specified  in  a  variety  of  ways.  Data  Structure  Diagram  (DSD  also 
called  Bachman  Diagram)  is  a  simple  method  used  to  represent  overall  record 
structures.  The  single  or  double  arrow  notation  is  used  to  express  relationships 
between  records  (nne-to-one,  one-to-many,  many-to-many  relation  ships),  shows  the 
relationships  among  records. 

The  relationships  are  identified  intuitively.  The  design  team  considers  potential 
relationships  among  records  that  have  been  defined.  A  relationship  may  exist  among 
three,  four  or  more  records.  At  this  point  the  design  team  must  discriminate  between 
theoretical  and  useful  relationships.    A  theoretical  relationship  can  exist  logically,  but 
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•  Projeci :  Personnel  Management  System. 

•  Problem  :  Individual  and  manual  data  processing. 

•  Objectives  :  To  design  and  implement  a  prototype 

personnel  management  system. 

1.  Providing  proper  data  for  decision  making. 

a.  Promotion  selection. 

b.  Assignment  management. 

c.  Management  of  personnel  resources 

for  education. 

d.  Welfare  &  morale. 

e.  Personnel  supply. 

2.  Reduction  of  manpower  and  time  by 

integrated  data  maintenance  and  processing. 

3.  Increase  in  data  accuracy  and  work  efficiency. 


Figure  5.1     Statement  of  scope  and  objectives. 

may  never  be  needed  in  practice.    Theoretical  record  relationships  were  discussed  in 
Chapter  III. 

1.  Record  structure 

In  order  to  satisfy  the  user's  requirement  we  will  derive  a  number  of  records 
from  personal  data.  Because  of  military  security,  we  will  prototype  similar  record 
model  instead  of  displaying  the  whole  personal  record.  From  the  information  in  the 
personal  record,  we  can  build  a  number  of  record  by  bundling  a  few  items  as  fields  in  a 
relational  model.  In  this  thesis,  we  will  generate  the  following  records  with  the 
underlined  field(s)  as  the  key: 

1)       MAIN     {SN,       NAME,       ORG_BRANCH,       C_TYPE,       BORN_DATE, 

BORN_PLACE) 

SN  :  Service  number 
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NAME  :  Name 

ORG_BRANCH  :  Original  branch 
C_TYPE  :  Commissioned  type 
BORN_DATE  :  Bom  date 
BORN_PLACE 

2)  M_EDUCAT     {CNME,     CLASS_SIZE,      START_DATE.      END_DATE. 
SNAME,   CLASS_MEAN) 

CNAME  :  Course  name 

CLASS_SIZE  :  Class  size 

START_DATE  :  Start  date 

END_DATE  :  End  date 

S_NAME  :  School  name 

CLASS_MEAN  :  Class  mean  points  •  '         • 

3)  EDUCATMN  {SN,   CNAME,   E_GRADE,MEAN)  — -  Intersection  record 
SN  :  Service  number 

CNAME  :  Course  name 
E_GRADE  :  evaluation  grade 
MEAN  :  Personal  mean  points 

4)  RANK  (RANKS,  P_QRDER,   TDATE) 
RANKS  :  Rank 

P_ORDER  :  Personnel  order 
T_DATE  :  Date 

5)  PROMOTE  (SiV,  P_QRDER)  — -  Intersection  record 
SN  :  Service  number 

P_ORDER  :  Personnel  order 

6)  AWARDPUN  (KIND.  P_QRDER^   T_DATE) 
KIND  :  Kind  of  award  and  punishment 
P_ORDER  :  Personnel  order 

T  DATE  :  Date 


69 


7)  A_P_MN  (S^,  E_QRDER)  -—  Intersection  record 
SN  :  Service  number 

P_ORDER  :  Personnel  order 

8)  A_P_P(ATiV^,   POINT) 

KIND  :  Kind  of  award  and  punishment 
POINT  :  Points  given  by  award  and  punishment 

9)  EXPERT  (5^,   MIZRTITLE) 
SN  :  Service  number 
EXPERTITLE  :  Expert  title 

10)  P_EVAL(SN,   GRADE.  TUkTE) 

SN  :  Service  number  .  . 

GRADE  :  Performance  evaluation 
T_DATE  :  Date 

11)  CAREERS  {SN,    SE_NO,    START_DATE,    END_DATE,  P_ORDER) 
Intersection  record 

SN  :  Service  number 
SE_NO  :  Serial  number 
STAR_TDATE  :  Start  date 
END_DATE  :  End  date 
P  ORDER  :  Personnel  order 


12)        UNTT(5ffJV2,   DUTY_TITLE,   UNIT) 
SE_NO  :  Serial  number 
DUTY_TITLE  :  Duty  title 
UNIT  :  Unit 

Precise  information  about  each  field  is  in  Data  Dictionary  in  Section  C.  of  this 
chapter. 

2.  Record  relationship  diagram 

As  was  mentioned  before,  the  fields  in  the  MAIN  record  are  fixed  items  that 
never  need  to  be  changed.   Therefore,  as  we  can  see  in  Figure  5.2,  ail  other  records  are 
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A-P-P 


AWARDPUN 


M_EDUCAT     ^ 


P_EVAL 


?JiNK 


UNIT 


EXPERT 


Figure  5.2     General  view  of  record  relationship  diagram. 

centrally  related  to  the  MAIN  record.  Each  record  has  its  own  individual  purpose,  for 
example,  AWARDPUN  record  shows  information  about  award  or  punishment  which  a 
certain  person  was  given  ,M_EDUCAT  record  shows  training  and  education  that  a 
certain  person  has  taken.  The  reason  that  we  show  record  structure  in  the  previous 
section  is  to  make  it  easier  for  the  user  to  understand  what  record  is  needed  for  what 
purpose.  Relationships  in  Figure  5.2  should  be  reorganized  by  intersection  record  to 
divide  complex  network  record  relationships.  Reducing  a  complex  network  to  a  simple 
relation  is  discussed  in  Chapter  III.  Figure  5.3  shows  the  final  record  relationship 
design  with  intersection  record. 
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A-P-P 


\f 


AWARDPUN 


EDUCATMN 


M  EDUCAT 


P  EVAL 


A  P  MN 


MAIN 


RANK 


UNIT 


A 


M 


^-^   CAREER 


EXPERT 


Figure  5.3     Record  relationship  diagram  with  intersection  record. 

C.       DATA  DICTIONARY 

A  data  dictionar\'  could  be  defined  as  a  collection  of  correct  information  about 
the  words  and  terms  used  by  an  organization  to  describe  its  data.    The  term  data 
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dictionary  is  used  to  indicate  a  collection  of  inlbrmanon,  that  is,  a  set  of  files  or  a 
database.  The  term  is  also  used  to  dscribe  the  mechanism  for  storing  data  in  the  fields 
and  databases,  that  is,  a  system  or  a  collection  of  computer  programs.  Data 
dictionaries  as  files  or  databases  contain  data  which  are  physically  stored  on  magnetic 
storage  media,  most  often  magnetic  disk.  Data  dictionary  systems  as  a  collection  of 
computer  programs  perform  the  functions  of  storing,  retrieving,  and  quite  often 
manipulating  and  passing  data  on  to  other  systems,  like  the  DBMS. 

The  six  major  steps  in  building  a  DDS(Data  Dictionary  System)  that  will  respond 
to  the  enterprise's  need  for  having  complete  control  over  their  data  resource  follow: 
[Ref  11:  p.56] 

(1)  Establishing  data  naming  and  definition  standards/conventions:  This  includes 
standardization  of  data  elements,  data  items,  and  data  definition  (DD)  naming 
conventions,  program  naming  conventions,  and  job  name  naming  conventions" 
at  minimum. 

(2)  Establishing  standard  abbreviations  and  acronvms:  This  includes 
standardization  of  abbreviations  and  acronvms.  as  well  as  of  establishing  the 
rule  to  define  a  term  the  first  time  'it  is  being  used  in  programs, 
documentation.reports.etc. 

(3)  Identifying  and  defining  "base  data"  data  elements:  This  includes  the 
identification  and  detinition  of  "product  data"  and  the  "division  or  department 
data"  of  the  enterprise,  both  of  which  are  essential  for  the  companv's 
existence. 

(4)  Identifying  and  defining  codes:  This  includes  identification  and  definition  of 
code  types  of  data  elements. 

(5)  Identifving,  defining,  and  standardizing  input,  update,  and  validation 
procedlires:  This  includes  identification,  deTinition.  and  standardization  oi  1,0, 
update  and  validation. 

(6)  Identifving  and  defining  data  characteristics:  This  includes  the  identification 
and  definition  of  the  characteristics  of  data. 

Management  of  a  database  is  usually  a  complex  process.  It  requires  the  database 
administrator  to  keep  track  of  all  the  database  and  user  view  definitions  as  well  as  their 
use.  Data  dictionaries  have  been  developed  to  aid  the  database  administrator  in  this 
task.  The  generation  of  the  data  dictionary  which  documents  functions,  data  bases, 
allowable  values,  formats,  and  their  interrelationship  should  be  initiated  at  this  point. 

The  Data  Dictionary  for  this  thesis  is  as  follow: 
Field  name:  sn 
Format:  character 
Width:  8 

Allowable  value:  less  than  100,000,000 
Description:  military  service  number  of  person. 
for  example,  77-15-3376,  73-05-5253. 
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Field  name:  name 

Format:  character 

Width:  15 

Allowable  value:  last  name,  first  name  middle  name 

Description:  name  of  person 

Field  name:  org_branch 

Format:  character 

Width:  20 

Allowable  value:  infantry,  engineer.etc. 

Description:  original  branch  that  a  person  was 

assigned  when  he/she  was  commissioned. 

sometimes  person  work  in  another  branch 

for  some  period  of  time. 

Field  name:  c_type 
Format:  character 
Width:  10 

Allowable  value:  ROTC,  KM A( Korean  Military  Academy),etc. 
Description:  commisioned  type  that  is  identified  by  the 
school  or  education  before  commision. 

Field  name:  born_date 
Format:  character 
Width:  8 

Allowable  value:  \TMMDD 
Description:  date  of  birth 

Field  name:  born_place 

Format:  character 

Width:  15 

Allowable  value:  city  of  Seoul,  Chunnam  do,.. 

Description:  birth  place,  a  special  city,  a  city  under  the 
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direct  control  of  the  government  or  do(province) 

Field  name:  c_name 

Format:  character 

Width:  20 

Allowable  value:  infantr\'  OBC,  engineer  OAC,etc. 

Description:  military  course  name,   a  list  of  the  types 

of  training  required  for  a  certain  job  or 

rank. 

Fieldname:  e_grade 

Format:  character 

Width:  15  ■  .  .      . 

Allowable  value:  outstanding,  middle, etc. 

Description:  evaluation  grade  which  is  given  at  the 

end  of  every  training  or  education  course. 

Field  name:  mean 

Format:  numeric 

Width:  5 

Allowable  value:  less  than  100 

Description:  personnel  average  value 

Field  name:  class_size 

Format:  numeric 

Width:  4 

Allowable  value:less  than  500 

Description:  number  of  students  in  class. 

class  size  is  needed  when  a  person's  position 
in  class  should  be  given  for  evaluation. 

Field  name:  start_date 
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Format:  character 
Width:8 

Allowable  value:  \TMMDD 

Description:  date  when  he/she  starts  a  certain  assigned 
job  or  education. 

Field  name:  end_date 

Format:  character 

Width:  8 

Allowable  value:  YYMMDD 

Description:  date  when  he/she  finish  a  certain  assigned  job 
or  education  course,   start  date  and  end  date 
is  needed  to  know  time  and  duration  of  person's 
assigned  job  or  education  course. 

Field  name:  sname 

Format:  character 

Width:  8 

Allowable  value:  Army  infantry  school,Army  engineer 

school,etc. 
Description:  school  name,   many  military  training  or 

education  courses  are  provided  by  many 

different  schools. 

Field  name:  class_mean 

Format:  numeric 

Width:  5 

Allowable  value:  less  than  100 

Description:  class  mean  grade 

Field  name:  rank 
Format:  character 
Width:  20 
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Allowable  value:2LT,lLT,Capt,etc. 
Description:  person's  rank 

Field  name:  p_order 

Format:  character 

Width:  20 

Allowable  value:  77-33  army,  78-13  army,etc. 

Description:  personnel  order  for  education,  assignment, 
promotion  etc.   p-order  has  many  different 
type  of  serial  number  for  each  type  of  order. 

Field  name:  t_date 
Format:  character 
Width:  20 

Allowable  value:  YYMMDD 
Description:  date 

Field  name:  kind 

Format:character 

Width:  20 

Allowable  value:staff  of  chief  awarding,  corps  commander 

awarding, etc. 
Description:  kind  of  award  or  punishment 

Field  name:  point 
Format:numeric 
Width:4 

Allowable  value:  greater  than  -5  and  less  than  5 
Description:  ditTerent  point  is  given  depend  on  the  type  of 
award  or  punishment. 

Field  name:  expertitle 
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Format:  character 

Width;  20 

Allowable  value:  CPA,  civil  engineer,etc. 

Description:  some  people  have  special  qualification. 

Field  name:  grade 

Format:  character 

Width:  2 

Allowable  value:  aa.ab,ba,cb,etc. 

Description:  this  field  is  composed  of  two  grades,  the  first 
grade  is  given  by  commander  and  the  second 
grade  is  given  by  vice-commander  by  the  level 
of  job  accomplishment. 

Field  name:  dutytitle 

Format:  character 

Width:  20 

Allowable  value:  platoon  leader. company  commander.etc. 

Description:  duty  title,   some  job  or  assigned  position 
is  required  for  promotion,   duty  title  is 
needed  for  job  assignment  or  promotion  selection. 

Field  name:  unit 

Format:  character 

Width:  25 

Allowable  value:  55x  227r  2bn  5co  2pl,48x  105r  70bn,etc. 

Description:  unit  is  composed  of  division(x), 

regiment(r), battalion!  bn),company(co),platoon(pn). 

Field  name:  se_no 

Format:  numeric 

Width:  7 

Allowable  value:  9293001, 7354023,etc. 
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Description:  serial  number,  unique  number  is  given  to 
every  unit. 
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VI.  DATA  BASE  IMPLEMENTATION 

A.  INTRODUCTION 

The  introduction  of  a  data  base  as  the  central  reservoir  of  data  affects  the  user 
organization  in  a  number  of  ways.  For  example,  it  changes  the  organization's  attitude 
to  data  requirements  and  management,  it  creates  new  authorities  and  it  brings  in  new 
skills.  It  also  enforces  greater  coordination  between  the  various  user  departments  and 
demands  stricter  adherence  to  standards.  A  good  implementation  scheme  should 
include  adequate  provision  to  tackle  these  problems,  in  addition  to  having  plans  for 
system  developments  and  scheduling  of  resources.  Much  of  this  would  be  planned  and 
controlled  by  the  DBA,  on  whose  abiUty  will  largely  append  the  success  of  the  venture 
-  provided  that  the  right  DBS  is  selected  in  the  first  place.  In  this  chapter  we  will 
discuss  these  issues:  relational  implementation  and  data  base  administration. 

B.  RELATIONAL  IMPLEMENTATION  OVERVIEW 

In  relational  systems,  data  relatibility  is  provided  by  the  ability  to  construct  new 
relations  from  existing  relations  by  the  use  of  the  relational  operators.  The  relational 
operators  may  require  access  paths  to  contain  or  represent  the  derived  relations.  The 
access  paths  may  exist  in  the  system,  or  they  may  be  constructed  by  the  system  as 
required.  For  instance,  a  join  can  be  implemented  as  a  separate  file,  as  a  set  of 
pointers,  or  by  storing  the  definition  of  the  join  and  generating  it  as  needed.  However, 
no  matter  how  it  is  implemented,  the  user  is  not  aware  of  the  exact  representation  and 
does  not  really  care  what  it  is. 

Since  a  user  is  not  explicitly  aware  of  the  access  paths  in  a  relational  system,  this 
may  lead  to  the  misconception  that  relational  systems  do  not  provide  access  paths. 
This  is  far  from  true.  As  in  a  hierarchical  or  a  network  system,  a  relational  system  may 
need  specific  nature.  The  existence,  and  maintenance  of  these  access  paths  may  be 
hidden  from  the  user.  Nevertheless,  they  exist,  and  their  implementation  is  one  of  the 
hardest  design  problems  in  a  relational  system. 

Relational  systems  can  be  differentiated  according  to  how  they  represent  derived 
relations  via  access  paths.  If  they  only  store  the  definition  of  a  derived  relation,  then 
the  access  paths  corresponding  to  the  physical  implementation  of  the  derived  relation 
are  destroyed  after  every  query.    In  this  case,  content  addressability  may  be  sutllcient 
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to  construct  the  access  paths  as  required.  For  example,  a  join  can  be  constructed  using 
conient  addressability  by  correlating  tuple  identifiers  fi*om  the  inverted  files,  for  the  two 
relations,  according  to  the  join  condition.  On  the  other  hand,  the  system  can  retain 
and  maintain  the  access  paths  corresponding  to  the  definition  of  a  derived  relation.  In 
this  case,  the  maintenance  of  these  access  paths  can  become  very  involved. 

There  are  currently  many  commercial  DBMS  products  that  claim  to  be  relational. 
Some  are  more  relational  in  name  than  in  actuality.  The  DBMS  should  model  data  as 
tables,  and  it  should  support  SELECT,  PROJECT,  and  unrestricted  JOIN  operations. 
A  system  that  supports  restricted  JOIN  operations  falls  in  a  gray  area.  Some  people 
would  call  the  system  a  relational  system  in  spite  of  this  limitation.  Others  would  call 
it  a  tabular  system. 

Relational  DBMS  can  be  divided  into  three  groups.  One  group  is  based  on  the 
data  language  SQL,  one  on  the  data  language  QUEL,  and  one  group  contains  system 
falling  into  neither  of  these  categories.  Three  major  SQL-based  DBMS  products  are 
SQL/DS.  System  R,  and  ORACLE.  System  R  is  a  research  system  developed  by  IBM 
for  the  study  of  relational  technology.  System  R  has  been  used  in  a  prototype  mode 
by  several  major  industrial  concerns.   SQL/DS  is  a  commercial  version  of  System  R. 

ORACLE  was  developed  for  operation  on  Digital  Equipment  Corporation  PDP 
minicomputers.  Since  its  organization,  ORACLE  has  been  converted  to  operate  on 
IBM  mainframes  as  well.  OR.A.CLE's  user  interface  is  based  on  SQUEL  II,  an  earlier 
version  of  SQL.  According  to  RSI.  ORACLE  will  soon  be  compatible  with  the  current 
version  of  SQL. 

QUEL  (QUEery  Language)  is  a  data  language  like  SQL.  QUEL  is  based  on 
tuple  relation  calculus.  QUEL  is  nonprocedural  and  allows  the  user  to  process  data 
without  concern  for  physical  data  structures.  The  data  base  product  INGRES  is  based 
on  QUEL.  INGRES  operates  on  Digital  Equipment  PDP  hardware  and  runs  under 
the  UNIX  operating  system.    IDM  500  is  also  based  on  QUEL. 

There  are  many  other  relational  DBMS.  There  is  even  a  microcomputer 
relational  product:  dBASE  II,  which  is  needed  by  Ashton-  Tate.  dBASE  II  operates  on 
CP/M-based  micros.  dBASE  II  is  an  example  of  a  relational  DBMS  that  restricts  join 
operations.   The  join  columns  must  be  indexed.   [Ref  7:  pp.437,438] 
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C.       IMPLEMENTATION  USING  DBASE  ill  ^ 

As  we  mentioned  before,  we  use  DBASE  111+  to  show  the  sample  application 
program  for  prototyping  in  this  thesis.  The  Korean  military'  personnel  management 
system  has  been  implemented  using  dBASE  III+  relational  DBMS  in  appendix.  As  a 
word  processor  allows  one  to  manipulate  characters,  words,  sentences  and  pages  to 
create  a  document  that  fits  one's  needs,  dBASE  III+  allows  one  to  work  with  fields, 
records,  and  files  to  manage  data  in  just  the  desired  manner. 

We  will  provide  basic  operations  to  implement  the  data  base  using  dBASEIII  + 
in  this  section. 

I.  CREATE 

First  of  all,  in  order  to  create  a  file,  CREATE  command  is  used  as  follows: 


.  CREATE  PARK 

Field  Name  Type      Width   Dec 

1  RANKS  Characte.-    20 

2  P_aRDER  Character    20 

3  TDATE  Character     8 


2.  USE 

A  file  called  PARK  has  now  been  created  on  the  data  base  by  I.    To  select  a 
file  to  work,  with,  we  should  use  USE  command: 


USE     PARK 
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3.  APPEND 

To  add  the  information  to  the  file,  use  the  APPEND  command.    APPEND 
lets  the  user  more  the  cursor  to  any  field  and  enter  or  change  the  inlbrmation. 


.  APPEND 

RANKS 
P_ ORDER 
TDATE 

RANKS 

P.ORDER 

TDATE 


2nd  lieutenant 
77-33  army 

03/2B/77 

1st    lieutenant 
7S-33    army 
04/01/79 


4.  LIST 

When  we  create  a  file  or  add  information  to  a  certain  file,  we  need  to  verify 
the  information  and  data  structure.  In  this  case,  we  use  LIST  command  to  list  a  data 
file's  contents  on  the  screen. 


.  LIST 

Record# 

RANKS 

P  ORDER 

TDATE   ' 

1 

2nd  1 1 eutenant 

77-33  army 

03/2B/77 

2 

1st  lieutenant 

78-33  army 

04/01/78 

.  LIST  FOR  RANKS  =  "2nd 

1 i  eutenant" 

Recard# 

RANKS 

P  ORDER 

TDATE 

1 

2nd  1 1 eutenant 

77—33  army 

03/20/77 

LIST  STRUCTURE 
Structure  for  database: 
Number  o-f  data  records: 
Date  of  last  update    : 
Field   Field  Name   Type 

1  RANKS 

2  P_ORDER 

3  TDATE 
tt    Total  »» 


C: PARK.dbf 

1 
01/09/87 

Width 

Character      20 

Character      20 

Character       B 

49 


Dec 
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5.  EDIT 

If  the  contents  of  data  file  is  changed,  the  EDIT  command  can  be  used. 
EDIT  allows  full  screen  operation. 


.  LIST 
Recard# 
1 
2 

RANKS 

2nd  lieutenant 

1st  lieutenant 

P_aRDER 
77-33  army 
, 78-33  army 

TDATE 

03/28/77 
04/01/78 

.  EDIT  2 

RANKS 

1st  lieutenant 

P  ORDER 

78-33  army 

TDATE  . 

04/01/78 

.  list 
Record^ 

"1 

RANKS 

2nd  lieutenant 

maj  or 

P_aRDER 
77-33  army 

■73-33  army 

TDATE 

03/28/77 

04/OL/79 
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6.  DELETE 

To  delete  records  from  a  delete  Hie.  we  use  DELETE  command. 


.  LIST 

Records  RANKS 

1  2nd  lieutenant 

2  major 

.  DELETE  RECORD  2 

1  record  deleted 
.  DISPLAY 

Record#   RANKS 

2  »fTiajor 

.     RECALL 

1  record    recalled 
.     DISPLAY 

Record**       RANKS 

2  major 


.  DELETE  RECORD  2 

1  record  deleted 
.  DISPLAY 

Recc;rd#   RANKS 

2  * ma J  or 

.  PACK 

1  record  copied 
.  LIST 
Record**   RANKS 

1   2nd  lieutenant 


P_DRDER 
77-33  army 
7S-33  army 


P_ORDER 
7b-33  army 


P_ORDER 
73-33  army 


P_aRDER 
75-33  army 


P_aRDER 
77-33  armv 


TDATE 

03/28/77 

04/01/78 

TDATE 

04/01/7B 

•  TDATE 

04/01/73 

TDATE 
04/01/78 


TDATE 
03/28/77 
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7.  SELECT 

To  use  more  than  one  data  file,  dBASE  III-^-  reserves  two  areas  of  memory 
for  data  file.  If  it  is  necessar>'  to  use  another  data  file  at  the  same  lime.  SELECT 
command  must  be  used.  • 


.     SELECT     1 

• 

.     USE    PORK 

.     SELECT    2 

.     USE    PROMOTE     INDEX    PROMOTE                                                                                                                                  | 

.     JOIN    WITH    PARK 

TO    TEMPFILE    FOR    P_ORrER    •=A->P_ORDER    FIELDS    SN,A->RANKS 

2    records    j 

oined 

.     USE    TEMPFILE 

.     LIST 

Record!*       SN 

RANKS 

1       20001 

2nd    lieutenant 

2       21554 

2nd    lieutenant 

8.  INDEX 
/  We  can  use  INDEX  command  to  sort  a  data  file  in  a  certain  order.    If  a 

specific  item,  not  die  whole  list,  is  wanted,  then  the  FIND  command  can  be  used  to 
display  on  the  screen. 


.      INDEX 

ON    P    ORDER    TO    KIM 

100*/. 

indexed                                 2 

Records    indexed 

.     USE    PARK     INDEX    KIM 

.     LIST 

Record** 

RANKS 

P    ORDER 

TDATE 

1 

2nd     1 1 eutenant  ' 

77-33    army 

03/28/77 

2 

1st     1 1 eutenant 

7B-33    army 

04/01/7Q 

.     FIND    77-33    army 

.     DISPLAY 

Record^ 

RANKS 

P    ORDER 

TDATE 

1 

2nd     lieutenant 

77-33    army 

03/28/77 
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D.       DATA  BASE  ADMINISTRATOR 

In  a  conventional  system,  files  belong  to  the  relevant  user  departments.  It  is  they 
who  are  responsible  for  the  accuracy,  consistency  and  up-to-dateness  of  data  in  the  file, 
although  regular  maintenance  on  their  behalf  is  normally  carried  out  by  the  data 
processing  staff.  In  a  data  base  where  all  company  data  are  centrally  held,  no  single 
user  department  can  be  responsible  for  it.  Instead  this  responsibility  is  exercised  by  the 
data  base  administrator  on  behalf  of  the  whole  company  with  a  view  to  preserving  the 
interest  of  both  current  and  future  users.  In  addition,  the  DBA  is  also  responsible  for 
creating,  expanding  and  improving  the  data  base  and  for  providing  user  facilities.  For 
a  small  data  base,  the  function  of  the  DBA  can  be  performed  by  an  individual  as  a 
part-time  job,  but  for  a  large  data  base,  the  function  can  require  the  full-time  services 
of  a  team.  To  be  effective,  the  DBA  should  represent  a  senior  position  with  sufficient 
authority  to  arbitrate  disputes  between  the  user  departments  on  data  base  usage,  and 
to  impose  decisions  in  case  of  deadlocks.  He  should  also  be  accepted  as  the  final 
authority  in  all  matters  relating  to  the  management  of  the  data  base. 

The  function  of  the  DBA  should  be  include  the  following  activities:  creation  of 
the  data  base,  performance  optimization,  data  protection,  specification  and 
enforcement  of  standards,  and  coordination  and  the  provision  of  the  user  facilities. 
David  defines  the  responsibility  of  DBA  as  follow: 

(1)  DBA  Data  Activity  Management  Responsibilities 
provide  data  base  standards 

establish  data  owner  ship,  retrieval,  and  modification  rights 
create  and  disseminate  recovery  procedure 
inform  and  train  users 
enforce  data  activity  policy 
publish  and  maintain  documentation. 

[Ref  7:  p.540] 

(2)  DBA  Database  Structure  Management  Responsibilities 

•  design  the  schema(s) 

•  provide  design  expertise 

•  control  redundancy 

•  maintain  configuration  control  of  change  requests 

•  schedule  and  run  configuration  control  meeting 

•  implement  schema  changes 
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•  maintain  user  documentation 

•  maintain  DBA  documentation. 
[Ref.  7:  p.544] 

(3)      DBA  Responsibilities  for  Database  System  Management  . 

generate  data  base  system  performance  reports 

investigate  user  performance  complaints 

analyze  reports  and  complaints 

tune  the  data  base  system 

tune  communications  software  and  operating  system  to  data  base  (when 
possible) 

evaluate  and  implement  new  features. 

[Ref  7:  p.548] 
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VII.  SAMPLE  PROGRAM  PROCESSING 

Personnel  management  system  (PMS)  is  a  menu  driven  program  organized  along 
functional  lines,  Each  major  function  in  the  system  corresponds  to  a  section  of  the 
User's  manual  and  selection  from  the  main  menu.  It  is  important  to  read  the 
information  or  the  feature  you  plan  to  use  before  you  use  it.  This  tells  you  exactly 
what  information  you  need  and  where  to  find  it. 

There  is  also  a  chapter  on  the  DRIVER  (or  main  menu)  section  of  PMS.  This  is 
very  important  to  read  before  you  start  using  PMS  as  it  describes  the  actions  required 
if  you  get  stuck  in  the  middle  of  a  program  and  cannot  get  out  or  if  the  system  crashes. 

This  manual  is  indicated  for  use  with  the  IBM  PC(AT).  You  have  been  provided 
3  diskettes:  dBASE  III  +  (I),  dBASE  III +  (II),  and  PMS.  You  must  "boot  up'  your 
computer  system  {which  should  be  equipped  with  a  hard  disk)  and  then  do  the 
following: 

1.  Copy  above  diskettes  into  the  hard  disk. 

2.  Type  "dbase"  (no  quotes  needed),  and  then  strike  the  return  key.  Once  the 
system  is  loaded,  you  will  see  the  "."(dot)  prompt  on  the  screen. 

3.  Type  "set  default  to  c"(no  quotes  needed)  and  then  the  return  key,  the  "."will 
appear  again.  Now  you  are  ready  to  use  the  personnel  management  database 
system(PMS). 

4.  At  this  point,  type  "do  driver"(no  quotes  needed)  followed  by  a  carriage  return. 
After  a  short  wait,  the  PMS  main  menu  will  appear  and  you  can  start  enjoying 
PMS. 

5.  You  have  to  follow  the  command  messages  which  appear  on  the  screen.  The 
various  options  of  the  main  function  of  this  system  are  specified  in  the  first 
message  (main  menu).  Enter  the  main  menu-letter  which  you  want.  This  will  be 
followed  by  another  message  menu  on  the  screen.  Select  the  menu-letter  which 
you  want,   and  follow  the  command  message  on  the  screen. 

6.  After  having  done  what  you  wanted,  you  can  return  to  the  previous  menu  by 
selecting  menu  option  "x". 
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A.       DRIVER 

The  driver  program  has  three  funaions:  First,  it  will  ask  what  kind  of  service 
you  require  and  then  call  that  function  your  task.  It  will  continue  until  you  finished. 
This  is  a  very  straight-forward  menu  driven  selection  process  and  does  not  require  any 
special  information  to  use.  Second,  much  more  complicated  part  of  the  DRIVER, 
deals  with  reconstruction  of  the  Data  Base  if  the  system  crashes  in  the  middle  of  a 
session.  The  DRIVER  always  stores  a  copy  of  every  user  interaction  in  a  file  called 
CRASH.TXT.  This  file  is  deleted  at  the  end  of  every  normally  terminated  run. 
However,  if  the  run  were  to  abort  abnormally  this  file  would  allow  you  to  recreate 
every  step  and  check  the  contents  of  the  Data  Base  for  accuracy.  Finally,  if  you 
change  the  data  in  all  system  programs,   the  data  is  used  continuously  after  changing. 

The  DRIVER  program  presents  the  main  menu  on  the  screen(  Figure  7.1).  If  you 
are  unfamiliar  with  the  7  options  presented  in  the  main  menu,  refer  to  the  preliminary 
information  section  so  that  you  can  refresh  yourself  on  what  each  option  is  all  about. 
Select  an  option  from  1  to  7.  Upon  option  selection  please  refer  to  the  respective 
section  you  have  just  selected. 


OFFICER    PERSONNEL   MANAGEMENT 




mm''  ^    :  :::HiiiiiiiHiyiii|iiiii 

1 

MENU 

i 

A.     PERSONNEL    ALLOTh 

1ENT    TABLE. 

1 

B.     LISTING. 

j 

1 

Any    query    that    requires    a    listing    or 

i  n'f  orraati  on 

1 

;j 

C.     REPORT (personal     record    card). 

D.     UPDATE. 

E.     EDIT. 

F.     DICTIONARY. 
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S.     CHANGE    DATE. 

ij 

X.     EXIT. 
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INFORMATION 

.       , 

nATF                                 TTMF 

UPDATED    BY 
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,  _,    C    Enter    selection     (    A    -    G,    or    X    to    E>:  1 1    ) 

'  =  ^iyiHyiyiiiiiiiiiiiiyiiiniiiyiiiiiiyiiyii 

Figure  7. 1     Olficer  personnel  management. 
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B.       TABLE 

The  Table  function  allows  you  to  obtain  the  number  of  ofTicers  for  each  rank. 
You  can  reach  this  section  by  entering  an  "A"  at  the  main  PMS  menu,  and  then  the 
following  screen(  Figure  7,2)  will  appear. 


PERSONNEL    ALLOTMENT 


"     '""     '  " "  ' '"'  '" " 

TABLE 

„.           ,.     ,.          .       ,.             .. 

1 

COMPANY    GRADE    OFFICERj                                         0 
FIELD       GRADE    OFFICER    :                                         5 
GENERAL    GRADE    OFFICER:                                         0 

TOTAL                                      :                                       5 

«««t    X.    Return    to    main    menu    «««»« 

' " 

ijjiiiiijliiiiliiiiiiiiiiijliiiijiiiiliilj 

INFORMATION 

M::;:in!:nn:;-:ii>iii:ii:!:!i::niil::H;n:::::!i:;;C;;:;;::ii-::;fi:::i::;;ii;; 

DATE 
Ul/31/a7 

TIME 
09: 10:32 

UPDATED    BY 

Enter 


to   E;:it 


Figure  7.2     Personnel  allotment. 

C.       LISTING 

The  listing  function  allows  you  to  obtain  listing  of  information  on  ofTicers.  You 
can  reach  this  section  by  entermg  an  "B"  at  main  PMS  menu.  It  is  designed  to  cycle 
back  to  the  main  LISTING  Menu  until  all  of  your  queries  are  answered.  It  will  then 
return  you  to  the  main  PMS  menu.The  available  listings  are  shown  the  followimz 
screen( Figure  7.3).  Please  pay  close  attention  to  the  section  on  what  information  you 
need  to  access  each  report. 

1.  Select  option  "'A"  to  list  all  officers 

As  the  title  suggests  this  section  will  provide  a  list  of  all  olficers  in  the  data 
file.  The  output  is  shown  below  (Figure  7.4). 

2.  Select  option  "B"  to  list  all  new  officers  for  assignment 

This  section  provides  a  list  of  all  new  officers  for  assignment.  The  following 
screen( Figure  7:5)  will  appear.  In  order  to  use  this  section  you  will  need  the  personnel 
order  of  tlie  new  ofiicer  exactly  as  it  is  shown  in  the  database.    A  complete  list  of  the 
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LISTING 


lililllillilliiillliililiilJiiliijiiiiiliilmiiiijO^ 


SUBMENU 


i:!:iii:i!l!HMMI!!!!in!Hi!I!!!IKl!;i!!!l!nnH!i!H!il!!.=:!!-!lH!!il-!i!i!l 


A.  List  «U  officers. 

B.  List  all  new  of -fleers  -for  assignment. 

C.  List  all  officers  educatec:. 

D.  List  all  officers  for  promotion  test. 

E.  Change  date 

X.  Return  to  main  menu 


DATE 
12/19/86 


TIME 
01:41:39 


INFORMATION 


UPDATED    BY 


Ij! 

liliililiiiiiiiili    ^    Enter    selection     (    A   -   E,    or    X    to   Em  it    ) 


3-:...; !..'..!.  i. 


Figure  7.3     Submenu  of  listing. 


1   major 

20001 

jung,jee  ho 

K.M.A«»33 

2   major 

21554 

ki m, sam  nam 

K.M.A1»33 

3   major 

350673 

joo.dae  j oon 

3i;.M.  A»13 

4   major 

22222 

kang.seon  mo 

K.M.At»35 

5   major 

23456 

park.Jae  bock 

K.M.A»33 

Press  any  key  to  continue... 

Figure  7.4     List  all  ofTicers. 

personnel  order  can  be  found  in  the  Appendix  of  this  thesis.  You  must  enter  the 
personnel  order  exactly  as  shown  or  the  system  will  not  be  able  to  match  the  correct 
personnel  order  and  will  return  an  error  message.  The  outputs  are  shown  below 
(Figure  7.6). 


92 


LIST  ALL  NEW  OFFICERS'  RECORD 

12/19/86 

01144:33 

■ 

List  for  what  personnel  order (  or  press  RETURN 

to  exit) 

(  e.g ;   86-35  ARMY  ) 

List  -for  what  rank    (or  press  RETURN  to  e^it) 

(e.g  >  1st  lieutenant) 

Figure  7.5     Query  to  find  out  commissioned  olFicers. 


■ 

r 

Page  No,      i 
12/19/86 

NEW  CQMMISSQNED  OFFICERS 

RANK    SERVICE       NAME               COMMISSONED 
NUMBER                              TYPE 

major   22222    kanq,seon  mo                 K.M.A«t35 
major   23456    park,jae  bock                K.ri.A«35 

Press 

any  key  to  continue... 

Figure  7.6     List  new  commissioned  officers. 

3.  Select  option  "C"  to  list  all  educated  officers 

It  will  provided  a  list  of  the  ollicers  educated  in  the  military  school.  The 
following  screen( Figure  7.7)  will  appear.  In  order  to  use  this  section  you  will  need  to 
enter  the  military  education  course  name  in  the  Appendix  exactly.  The  outputs  are 
shown  below(  Figure  7.8). 
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Ins 
LIST  EDUCATION  RESULTS  OF  EACH  OFFICER.  01/31/87   09:20:29 


List  ior    what  course  name (  or  press  RETURN   to  exit) 
(  s.q    — -INFANTRY  Q.A.C«234  ) 


Figure  7.7     Query  education  results  of  each  officer. 


Page  No.      1 
12/19/B6 

^ 

LIST 

SERVICE 
NUMBER 

NAME       COURSE  NAME          EVALUATION 

GRADE 

21334 
23456 
5S0673 

kim.sam  nam               in-fantry  o.a.ct»234 
park.Jae  bock             in  +  antry  o.a.cl»234 
joo,da«  joon              Infantry  o.a.cl»234 

Figure  7.8     List  education  results  of  each  ofTicer. 

4.  Select  option  "D"  to  list  all  officers  for  promotion  test 

This  will  provide  a  list  of  all  ofikers  for  the  promotion  test.  The  following 
screen( Figure  7.9)  will  appear.  In  order  to  use  this  section  you  will  need  the  promotion 
year  and  rank  (in  the  .Appendix)  exactly.   The  outputs  are  shown  below( Figure  7.10). 
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LIST  ALL  OFFICERS  FOR  PROMOTION  TEST. 


12/19/86   01j48:24 


List  for  what  rank  (or    press  RETURN  to  exit) 

(e.g  >  1st  lieutenent) 

What  is  a  promotion  year''(or  press  RETURN  to  exit) 
(e.g >  32) 


Figure  7.9     Quer>'  to  find  out  all  olTicers  for  promotion  test. 


Page  No. 
01/31/07 


LIST  ALL  OFFICERS  FOR  PROMOTIUN  TETiT 


SEVir:E 
rauMBER 

NAME 

CDMMISSaNEC 
TYPE 

PERSONNEL 
ORDER 

2000 1 
21554 

ju(ig,jee    ho 
tam.sam    nam 

K.H.A»:.3 
K.M. A«33 

B4-33    army 
84-33    Army 

Press  .any  t  ey  to  continue., 


Figure  7.10     List  all  olFicers  for  promotion  test. 

D.   REPORT  (  PERSONNEL  RECORD  CARD) 

The  REPORT  function  allows  you  to  obtain  detailed  information  of  each 
officer's  history.  You  can  reach  this  section  by  entering  a  "C"  at  the  main  PMS  menu. 
You  will  remain  in  the  REPORTS. PRG  untill  all  of  your  queries  are  answered.  It  will 
then  return  you  to  the  main  PMS  menu.  The  following  screen( Figure  7.11)  will 
appear.  In  order  to  use  this  section  you  will  need  the  service  numbers  exactly  as  it  is 
shown  in  the  data  base.  A  complete  list  of  the  service  number  can  be  (bund  in  the 
Appendi.K  of  this  thesis.    The  outputs  are  shown  below(  Figure  7.12). 
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PERSONNEL  RECORD  CARD.  12/19/86   01:4^:2= 


List  -for  what  servtca  number   (or  press  RETURN  to  exit) 
(e.g >    21334). 


Figure  7.11     Query  to  find  out  personnel  record  card. 


Page  No. 

1 

01/31/B7 

PERSONNEL  RECORD  CARD 

RANK 

SERVICE    NAME 
NUMBER 

ORIGINAL  BRANCH 

major 

21354    kim,sam  nam 

in-f  antry 

Figure?.  12     Personnel  record  card. 

E.       UPDATE  AND  EDIT 

The  UPDATE  and  EDIT  function  allow  you  to  change  fields  in  any  file.  It  also 
changes  any  other  files  that  were  alFected  by  your  changes.  It  is  very  important  that 
you  are  exact  with  your  changes  because  the  impact  of  a  mistake  could  have  wide 
reaching  implications.  You  can  reach  this  section  by  entering  "D"  and  "E"  for  adding 
and  changing  at  the  main  PMS  menu.  The  update  and  edit  program  are  almost  the 
same.  Therefore,  This  will  be  an  explaination  of  the  EDIT  function  only.  The 
followmg  sub-menu(  Figure  7. 13)  will  appear  on  the  screen. 
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EDIT 


PERSONNEL 


RECORD 


^    -..*  ^   ^    U.^   t' 

:::;:::  :: 

•.;;•:::::,.::::.:•::=:.::::::::■:::. :;„t.. :,::::■,:.::  :::• 

SUBMEMU      1 . 

A. 

Edit  personal  personne) 

record 

F. 

Edit  per-formance  evaluation 

B. 

Edit  expert  record 

record 

C. 

Edit  military  education 
resLil  t 

G. 

Edit  assignment  record 

D. 

Edit  promotion  record 

I. 

Change  date 

E. 

Edit  award  and  punishment  record 

X. 

Return  to  main  menu 

DATE 
01/31/87 


TIME 
09:21:08 


INFORMATION 


UPDATED  BY 


:i;;!;!!;;!;;nCEnter  selection  (A  -G,  I,  or  X  to  return  to  ma  menu) 


Figure  7.13     Submenu  for  changing  personjiel  records. 

1.  Select  option  "A"  to  ctiange  personnel  records 

This  will  allow  you  to  change  any  fields  in  the  MAIN. DBF  file.  You  must  be 
very  careful  when  changing  the  service  number  because  the  other  files  will  be  changed 
to  this  menu  value  as  well  as  the  MAIN  file.  The  following  screeni  Figure  7.14)  will 
appear.  You  must  know  the  service  number.  Failure  to  do  so  may  result  in  the  wrong 
information.  After  entering  the  service  number,  the  following  screen(Figure  7.15)  will 
appear,  and  then  you  may  enter  new  data  or  change  data. 


Ins 


EDIT  PERSONNEL  RECORD 


01/31/B7   09:34:17 


Edit  for    what  service  number  (  or  press  RETURN   to  ev.it) 


Figure  7.14     Quer\'  to  change  personnel  records. 
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1 

Ins 

EDIT  PERSONAL  PERSONNEL  RECORD 

< 

[ 
i: 

SERVICE  NUMBER  :  21554 
3RIGINAL  BRANCH:  infantry 
:OMMISSIQN  TYPE:  K.ri.A«33 

NAME ;  1. 1  m .  sam  nam 
BORN  DATE:07/21/54   BORN  PLACE: chunnam  do 

CURSOR 

Character;  Le-ft  Right 
Word:  HOME  END 
Field:  Up     Down 
Insert  Mode:  Ins 

DELETE 

Character:  DEL 
Field:      Y 
Record:    "U 

RECORD 
Previous  Record: 
Ne>:t  Record: 
Done/Save: 
Abandon: 

PgUp 

PciDn 

•  END 

ESC 

Figure  7.15     Screen  for  changing  personnel  records. 

2.  Selection  option  "B"  to  change  expert  records 

This  will  allow  you  to  change  any  files  in  the  EXPERT.DBF  file.  The 
following  screen(  Figure  7.16)  will  appear.  You  must  know  the  service  number  and 
expert  title,  failure  to  do  so  may  result  in  the  wrong  information.  After  entering  the 
service  number  and  expert  title,  the  screen  will  be  displayed  as  follows(  Figure  7.17), 
and  then  vou  mav  enter  or  chanee  data. 


Ins 


Caps 


EDIT  EXPERT  RECORD 


12/19/86   02:30:02 


Edit  -for  what  service  numoer  (  or  press  RETURN   to  exit) 


Figure  7.16     Querv-  to  change  expert  records. 
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In« 


EDIT 

SERVICE    NUMBER I  21S54 

EXPECfT    TIITLE;  c.p.a 


EXPERT 


C    Q    R    D 


CURSOR 

DELETE 

RECORD 

Character:  Left  Right 

Character i 

Del 

Previous  Record 

.PgUp 

Word:   Home  End 

Field: 

^Y 

Next  Record: 

PgDn 

Field:  Up   Down 

Record: 

-u 

Done/Save: 

-End 

Insert  Mode:  Ins 

Abandon: 

Esc 

Figure  7.17     Screen  for  changing  expert  records. 

3.  Select  option  "C"  to  edit  militar}'  education  results 

This    allows    you    to    change    rmhtar\'    education    results,     you   will    see    the 
following  sub-menu  screen(  Figure  7.18). 


EDIT      MILITARY         EDCATION 


SUBMENU 

' 

A. Edit  mil 
B.Edit  per 
C.  Change 
X.  E,-<it 

itary  education 
-sonal  education 
data 

resul ts 
results 

" 

T  MPTlPM^iT  T  DM 

DATE 
12/19/B6 

TIME 
U2:32: 17 

UPDATED  BY 

'    C     Enter    selection     (    A    -    C,     or    X    to    Exit     ) 


Figure  7.18     Submenu  for  changing  military  education  results. 
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If  you  select  option  "A"  from  the  inilitar>'  education  sub-menu,  you  will  see 
the  following  screen(  Figure  7.19).  This  will  allow  you  to  change  any  files  in  the 
M_EDL'CAT.DBF  file.  You  must  know  the  militan'  education  course  name(in 
Appendix)  exactly.  After  entering  the  course  name,  the  following  screen(  Figure  7.20) 
will  appear,  and  then  enter  or  change  data. 


EDI"'  1IL:T.^RV  education  P:£3ULT 


12  '10/56 


Edit  ror    wnat  class  naine  (  or  press  =£T'Ji=iN   to  exit) 


Figure  7.19     Quen.'  to  change  militan-'  education  results. 


Ins 


EDIT 


MILITARY 


EDUCATION 


RESULT 


COURSE  rJAME:  in  +  antry  o.a.c#234 


START  DATE:   06/01 /B2 


SCHOOL  NAME:  army  in+antry  school 


CLASS  SIZE: 


END  DATE: 


11/20/82 


MEAN  POINT  OF  CLASS:  92. 


CURSOR 

DELETE 

RECORD 

Character:  Le-f  t  Right 

Character: 

Del 

Previous  Record 

:  PQUp 

Word:    Home  End 

Field: 

-Y 

Np-:t  Record: 

(-  gf^ri 

Field;  Up    Down 

Record 

-u 

Dnne/save: 

ETND 

Insert  Mode:   Ins 

Abc-ndon; 

Esc 

Fieure  7.20     Screen  for  chan^ine  militan.'  education  results. 
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If  you  select  option  "B"  from  the  niilitan.'  education  sub-menu,  you  -will  see 
the  following  screen(  Figure  7.21).  This  will  allow  you  to  add  and  change  any  fields  in 
the  EDUCATMN.DBF.  you  must  know  the  militar>'  educaiion  course  name  and 
service  number  (in  Appendix)  exactly.  After  entering  the  course  name  and  service 
number,  the  following  screen( Figure  7.22)  will  appear  on  the  screen,  and  then  you  may 
enter  or  chanee  data. 


EDIT  PERSONAL  EDUCATION  RESULT 


12/19/86   0::34!20 


Edit  -for  what  service  number 

Edit  *ar  what  class  name 

(  or  press  RETURN  to  exit) 


Figure  7.21     Queries  to  change  personal  education  result. 


Ins 


EDIT       MILITARY  EDUCATION         RESULT 


SERVICE    NUMBER:     21554 


GRADE:     outstanding 

(e.g    — >    outstanding) 


COURSE    NAME;      in+antry    o.a.c#234 


MEAN: 


93.50 


CURSOR 

DELETE 

RECORD 

Character:  Le+t  Right 

Character: 

Del 

Previous  Record 

PoUp 

Word:   Home  End 

Field: 

'  Y 

Ne::t  Record; 

•^gOn 

Field:  Up   Down 

Record: 

U 

Done/ Save: 

End 

Insert  Mode;  Ins 

Abandon: 

Esc 

Figure  7.22     Screen  for  changing  personal  education  results. 


101 


4.  Select  option  "D"  to  change  the  promotion  records 

you  will  see  the  following  sub-menu  screen{ Figure  7.2?). 


EDIT      PRMOTION      RECORD 


•::: 

J 

1 

SUBMENU 

;r::;;!:ti;:;i:::::;rt:;:;:: ;;;:::;:::;;;:;;:::  :i::;:::::::r;::::::::::::::r:;;:;; ;;;":;:   | 

\\ 

I 

A. Edit    promotion    record 
B.Edit    r;ei"3onal     promotion 
C. Change    date 
X.E><it 

record 

:::, 

,              , 

. 

.ill 

INFORMATION 

1 

DATE                          TIME 
ir/19/G6                 01:35:32 

UPDATED    BY 

iiil 

C    Enter    selection     (    •^    -    C.     or    X    to    Zy.it     )     :     ;     ] 

Figure  7.23     Submenu  for  changmg  promoiion  records. 

If  you  select  option  "A"  from  the  above  sub-menu,  you  \\ill  see  the  following 
screen( Figure  7.24).  This  will  allow  you  to  add  and  change  any  fields  in  the 
R.A.NK.DBF  file  You  must  know  the  promotion  order(in  Appendix)  exactly.  .After 
entering  the  promotion  order,  the  following  screen(  Figure  7.25)  will  appear,  and  then 
enter  data  or  chanae  data. 
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EDIT  PROMOTION  RECORD 


1^/19/86   02:37:1: 


Edit  -for  what  promotion  order  (  or  press  RETURN   to  exit) 


Figure  7.24     Quen'  to  change  promotion  record. 


Ins 

E 

D  I  T 

p  R  a  n  0  T 

I  0  N 

R  E 

CORD 

PROMOTION  ORDER:  77-33  army 
RANK:  2nd  lieutenant 


DATE:     03/28/77 


CURSOR 

DELETE 

RECORD 

Character:  Le-ft  Right 

Character : 

Del 

Previous  Record 

:PgUp 

Word;    Home  End 

Field: 

-  Y 

Ne>;t  Record: 

F  ylJn 

Field;  Up    Down 

Record 

-u 

Done/save: 

END 

Insert  Mode:   Ins 

Abandon; 

Esc 

Figure  7.25     Screen  for  changing  for  promotion  record. 

If  you  select  option  "B"  from  the  add  and  edit  promotion  record  sub-menu, 
you  will  see  the  following  screen( Figure  7.26).  This  will  allow  you  to  add  and  edit  any 
fields  in  the  PROMOTE. DBF.  You  must  know  the  service  number  and  promotion 
order  {in  .Appendix)  exactly.  After  entering  the  service  number  and  promotion  order, 
the  following  screen(  Figure  7.27)  will  appear,    and  then  you  may  enter  or  change  data. 
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EDIT  PERSONAL  PROrCTION  RECORD 


I2/19/S6   02:C7:2B 


Edit  -for  what  service  number  , 

Edit  -for  what  promotion  order 
(  or  prsss  RETURN  to  exit) 


Figure  ".26     Queries  to  change  personal  promotion  record. 


EDIT   CEFSONAL   PROMOTION 

RECORD. 

e 

f 

SERVICE  NUMBER:    21554 
9R0M0TI0N  ORDER:   77-33  army 

CURSOR 

Character:  Le-ft  Right 
Word:   Home  Snd 
Field:  Ud   Down 
Insert  Mode:  Ins 

DELETE 

Character: 

Field: 
Record: 

Del 

RECORD 
Previous  Record 
Ne>;t  Record: 
Done/Save: 
Abandon; 

PgUo 
PgDn 
"End 

Esc 

Figure  7.27     Screen  for  changing  personal  promotion  record. 

5.  Select  option  "E"  to  change  award  and  punishment  records 

This  will  allow  you  to  change  award  and  punishment  records.  The  following 
sub-menu  screen(  Figure  7.2S)  will  appear  on  the  screen. 

If  you  select  option  "A"  from  the  award  and  punishment  sub-menu,  you  will 
see  the  following  screen(  Figure  7.29).  This  will  allow  you  to  add  and  change  any  fields 
in  the  A_P_P.DBF  you  must  know  the  award  and  punishment  name  (in  Appendix) 
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1        EDIT       CWftRD      rUNIShrit,\T       RECCRD 


SUBMENU 


A. Edit  award  and  punishment  points 

B.Edit  award  and  punisnment  record 

C.Edit  personal  awara  and  punisnment  record 

0. Change  date. 

X  .  E;;  1 1 


INFORMATION 


DATE 
12/19/36 


TIME 
02:37:54 


UPDATED  BY 


Ijiiliinniniinnn    C    Enter    selection     (    A    -    D,    or    X    to    E;:i t    )     ;     :     Jiiliiiiiiiniljjnn! 


Figure  7.28     Submenu  for  changing  award  and  punishment  records.. 

exactly.     .After    entering    the    award    and    punishment   name,     the    following    screen 
{Figure  7.30)  will  appear,   and  then  you  may  enter  or  change  data. 


EDIT  AWARD  AND  PUNISHMENT  POINT 


12/19/36   02:43:43 


Edit  -for  wnat  ^lnd  o+  awara  and  punisnment 
(  or  press  RETURN  to  exit; 


Figure  7.29     Quer\'  to  change  award  and  punishment  points. 
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1 

EDIT   A  W  A 

=?D   AND   PUIMISmMHN 

r   N  A  M  E 

AWARD  AND  PUNISHMENT  NAME: 
ASSIGNED  POINT          1.5 

army  commander  awarding 

CURSOR 

Character;  Ls+t  Right 
Word:   Home  End 
Field:  Ud   Down 
Insert  Moae:  Ins 

DELETE 

Character:  Dei 
Field:      -^Y 
Record:     ^U 

RECORD 
Previous  Record: FgUc 
Ne;:t  Record;     PgDn 
Done.- Save;        'End 
Abandon:          Esc 

Figure  7.30     Screen  for  changing  award  and  punishment  points. 

If  you  select  option  "B"  from  the  award  and  punishment  sub-menu,  you  will 
see  the  following  screeni.  Figure  7.31).  This  will  allow  you  to  add  and  edit  any  fields  in 
AWARDPUN.DBF  file.  You  must  know  the  personnel  order  (in  .Appendix)  exactly. 
After  entering  the  personnel  order,  the  following  screen( Figure  7.32)  will  appear,  and 
then  vou  mav  enter  or  chanee  data. 


EDIT  AWARD  AND  PUNISHMENT  RECORD 


12/19/96   02:44:11 


idit  •for  what  oersonnel  order 
(  or  press  RETURN  to  exit) 


Figure  7.31     Quen.'  to  change  award  and  punishment  record. 
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EC  IT  AKARD  AND  PUNISHMENT  RECORD. 


PERSONNEL  ORDER:  77-100  army 

AWARD  AND  PUNISHMENT  NAME:  sta-f-f  oi    chie-f  awarding 

DATE:  09/21/77 


CURSOR 

Character:  Le-rt  Right 
Word:   Home  End 
Field:  Up   Down 
Insert  Mode:  Ins 


DELETE 

Character;  Del 
Pieldf      --Y 
Record:     ^U 


RECORD 
Previous  Record:PgUD 
Next  Record:     PgDn| 
Done/ Save:       ^Endl 
Abandon:         Esc 


Figure  7.32     Screen  for  changing  award  and  punishment  record. 

If  you  select  option  "A"  from  the  award  and  punishment  sub-menu,  you  will 
see  the  following  screen{ Figure  7.33).  This  will  allow  you  to  add  and  edit  any  fields  in 
A_P_\'I\.DBF  file.  You  must  know  the  service  number  and  personnel  order(in 
Appendix)  exactly.  After  entering  the  service  number  and  personnel  order,  the 
following  screen(fig  7.34)  will  appear,   and  then  you  may  enter  or  change  data 


EDIT  PERSONAL  AWARD  AND  PUNISHMENT  RECORD 


12/19/86   02:44:29 


Edit  -for  what  service  numoer 

Edit  -for  what  personnel  order 
(  or  press  RETURN  to  e>;it) 


Figure  7.33    Query  to  change  personal  award  and  punishment. 
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EDIT  PRSONAL  AWARD  AND  PUNISHMENT  RECCRD 


SEP, VICE  NUMBER: 


2:554 


PERSONNEL  ORDER:      77-100  army 


CURSOR 

DELETE 

RECORD 

Character:  i_ett  R 

.ght 

Character: 

Del 

Previous  Record 

•  PgUo 

Word:   Home  End 

r lela: 

'"Y 

Next  Record: 

PgDn 

Field:  Up   Down 

Record: 

^U 

Done/ Save: 

"End 

Insert  Mode:  Ins 

Abandon: 

Esc 

Figure  7.34     Screen  for  changing  personal  award  and  punishment  record. 

6.  Select  option  "F"  to  change  performance  evaluation  record 

This  will  allow  you  to  add  and  change  any  fields  in  the  P_EVAL.DBF  file. 
The  following  screen(  Figure  7.35)  will  appear. 

You  must  know  the  service  number  and  evaluation  date,  failure  to  do  so  may 
result  in  the  wrong  information.  After  entering  the  ser-'ice  number  and  evaluation 
date,  the  following  screen( Figure  7.36)  will  appear,  and  then  you  may  enter  or  change 
data. 


EDIT  PERFORMANCE  EVALUATION  RECORD 

Ins 

01/31/37 

10:33 

Edit  -for  what  service  number  . 

Edit  -for  what  rating  date  (e.g 

(  or  press  RETURN  to  e.:  1 1 ) 

;  03/10/86 

03/10/8 

21 554 

Figure  7.35     Queries  to  change  performance  evaluation  records. 
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EDIT   PERFORMANCE    EVALUATION 


SECDPD 


SERVICE  NUMBER:  XXXXXXXX 

GRADE:  XX 

ie.g — >  ab) 


RATING  DATE: 


99/99/99 


CURSOR 

DELETE 

RECORD 

Character;  Le-ft  Right 

Character: 

Del 

Previous  Record: F9U0 

Word:   Home  End 

Field:   . 

•^Y 

Next  Record:     PgDn 

Field:  Up   Down 

Record: 

-u 

Done/Save;       "^End 

Insert  Mode:  Ins 

Abandon:         Esc 

Figure  7.36     Screen  for  changing  performance  evaluation  records. 

7.  Select  option"G"  to  change  the  assignment  record 

This  will  allow  you  to  add  and  change  any  fields  in  the  CAREER.DBF  file. 
The  following  screen(  Figure  7.37)  will  appear  on  the  screen,  you  must  know  the 
service  number  and  personnel  order  (in  Appendix)  exactly.  After  entering  the  service 
number  and  personnel  order,  the  following  screen{Figure  7.38)  will  appear,  and  then 
vou  mav  enter  or  chanee  data. 


EDIT  PERSONAL  ASSIGNMENT  RECORD 


12/19/86   02:45:31 


Edit  -for  what  service  number  . 

Edit  ■for  what  oersonnel  order 

(  or  press  RETURN  to  exit) 


Figure  7.37     Queries  to  change  personal  assignment  record. 
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EDIT    PERSONAL 


ASSIGNMENT 


RECC=D 


SERVICE  NUMBER:  XXXXXXXX 

RANK:  XXXXXXXXXXXXXXXXXXXX 

START  DATE:      99/99/99 


PERSONNEL  ORDER: 
DUTY  TITLE: 
END  DATE: 


XXXXXXXXXXXXXXXXXXXX 
XXXXXXXXXXXXXXXXXXXX 

99/99/90 


UNIT 


XXXXXXXXXXXXXX XXX XXXXXXXX   CLASSIFY: 


XXX XX  DUTY  EVALUATION:  XX 


CURSOR 

DELETE 

RECORD 

1 

1 

Character:  Ls-ft  Right 

Character: 

Dei 

Previous  Record 

PaUo 

Word:   Home  End 

Pxel=: 

^Y 

Ne:;t  Record: 

PgDn 

Fisid:  Ud   Down 

Recard: 

"U 

Done.  Save: 

End 

Insert  nods;  Ins 

Abandon; 

Esc 

Figure  7. 38     Screen  for  changing  personal  assignment  record. 

F.       DATA  DICTIONARY 

The  main  menu  of  the  PMS  system  (OPTION  F)  allows  you  to  access  the  data 
dictionary.  Through  the  dictionary'  menu,  you  can  find  out  what  a  variable  name  is 
and  how  to  enter  it  into  the  computer  (option  A),  fmd  out  the  structure  of  commonly 
used  data  files  (option  B),  find  out  where  a  variable  is  used  in  these  files  and  modules 
(option  C)  atid  fmd  out  other  features  of  the  dictionary'  with  an  exit  back  to  main  PMS 
menu  (option  D).  By  doing  this,  you  have  more  interactive  flexibility  when  using  the 
system.  You  must  still  have  some  idea  about  what  a  variable  is  named  before  you  can 
list  the  file  structure  and  retrieve  the  exact  variable  name.  The  following  screen 
(Figure  7.39)  will  appear. 

1.  Select  option  "X"  to  find  out  element  name  in  the  file 

This  allows  you  to  ask  questions  about  element  and  how  they  are  entered  into 
the  computer.  For  example,  you  know  the  variable  name  or  at  least  a  few  letters  of  it. 
You  will  see  DO  YOU  WANT  A  PRINTOUT?  Y  OR  N  If  you  desire  a  hardcopy 
printout  of  the  information,  you  would  ready  your  printer  at  this  time  and  enter  a 
capital  Y.  If  you  do  not  desire  a  printout,  enter  N.  The  information  you  will  receive 
will  be  element  name,  full  name,  type,  frequency  of  update  and  comments.  If  you 
entered  a  few  letters  of  the  name,  you  may  get  several  element  names  and  values.  .Ml 
of  the  element  names  will  appear  first,  then  all  of  the  full  names  will  appear  second, 
and  so  forth.    You  can  then  choose  the  one  you  want  and  get  a  clean  copy  of  the  exact 
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D^TA  DICTIONARY  INQUIRIES 


SUBMENU 

A 

• 
What  15  "^^'l'  and  how  do  I  enter  it  into  the 

cotTiputer 

B. 

What  type  o-f  information  does  a  particular 

file  cont  ai n? 

C 

What  file  contains  a  particular  variable? 

D 

Dictionary  in+ormation. 

E 

Change  date 

X 

E>:it 

DATE 
01/31/87 


TIME 
10:38: ; 


INFORMATION 


UPDATED  BY 


C  Enter  selection  (  A  -  E.  or  X  to  E::it  ) 


Figure  7.39     Submenu  of  data-dictionary. 

element  name,  if  desired.  REQUIRED  INFORMATION-  The  element  name  or  at 
least  a  few  letters  of  it.  You  may  obtain  this  first  through  dictionar\'  option  2  if  you 
know  what  file  it  is  used  in. 

2.  Select  option  "B"  to  find  out  used  data  files 

This  allows  you  to  discover  how  certain  files  are  structured.  The  options  are 
alphabetic  and  they  represent  the  commonly  used  data  files  in  PMS.  You  will  see  the 
following  screen  (Figure  7.40). 

You  will  then  enter  the  letter  of  your  selection.  If  you  enter  something  besides  the 
menu  options,  you  will  see  the  same  screen.  If  you  want  to  leave  this  portion  of  the 
dictionary',  select  the  letter  for  "X".  You  will  then  be  asked  if  you  want  a  printout.  If 
you  do,  you  ready  your  printer  at  this  time,  and  then  enter  a  capital  Y.  If  you  do  not 
want  a  printout,  type  N. 

This  option  allows  you  to  discover  the  exact  variable  names  (listed  as  fields) 
used  in  a  file. 

3.  Select  option  "C"  to  find  out  used  modules 

This  portion  of  the  dictionar\'  allows  you  to  make  queries  about  where  certain 
variables  are  used  throughout  PMS.  For  example,  if  you  wanted  to  know  where 
CNAME  was  used,  you  would  enter  the  variable  name  (or  what  you  remembered  of  it) 
when  vou  see  PLEASE  ENTER  THE  VARIABLE  NAME--  vou  will  then  be  asked    if 
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DATA  DICTICMftP.Y  ABOUT  DATA  FILE  STRUCTURE 


_ ._ _ 

, " '  1          SLJBnENU 

1 
A.    Main    -file                                                                    H. 

Award    and    punishment    point    -file-iij 

B.    Military    eaucation    -file                             I. 

E;;pert    *ile 

:t: 

C.    Personal    eaucatian    tila                              J. 

Peri^ormancB    evaluation    -file 

0.    Rank    -fiie                                                                    K. 

Military    careers    -i'.  e 

E.    Promote    +ils                                                            L. 

File    -lie 

r;: 

User    -file 

G.    Personal    award    ana    punisnment               N. 

Change   date 

•file                                                                          X. 

Return    to    main    menu 

!            r  Mfmf-.M/\"r  T  r-ihi 

—^^mmmMm-'-m:^'^mmmmm 

1                          1  iDnarcn    cv 

ir/io/ai                  0C:48: 17 

§y 

■    CEiter    selection     iA    -    N,    or    X    to    return    to    mam    menu)     :     :     llliyOHHiiinill 

Figure  7.4D     Submenu  to  detect  data  structure. 

you  want  a  pnntout.    If  you  do,  ready  your  printer  first,  then  type  a  capital  Y.    If  not, 
type  N. 

The  information  you  receive  will  list  the  name  of  the  file  or  module  where  it  is 
used,  then  the  type  (file  or  module).  BE  CAREFUL-  If  you  listed  only  a  portion  of 
the  variable  name,  you  may  get  a  list  of  where  all  the  variable  names  are  used. 
However,  by  judiciously  using  this  option  with  OPTIONS  A  and  B.  you  can  have  the 
flexibility  of  discovering  where  variables  are  used  (OPTION  C),  the  exact  variable( field) 
name(OPTION  B).and  how  to  enter  it  into  the  computer  (OPTION  A).  REQUIRED 
INFORMATION-- 

The  variable  name  or  at  least  a  few  letters  of  it.  You  may  obtain  this  first 
through  dictionar}'  option  B  if  you  know  at  least  one  file  m  which  it  is  used. 

Each  portion  of  the  data  dictionan.'  has  a  menu  to  assist  you  m  entering  the 
required  data  for  your  inquin,'.  However,  if  you  find  you  can  t  get  out  of  the  dictionary' 
for  some  reason,  type  HELP  in  all  capital  letters  when  asked  for  a  variable  name. 
Then  answer  N  to  the  question  about  wanting  a  printout.  This  will  allow  you  to 
return  to  the  main  dictionan.-  menu  and  then  return  back  to  the  main  PMS  menu 
through  OPTION  D  or  OPTION  X 
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4.  Select  option  "W  to  find  out  the  other  features 

This  allows  you  to  exit  the  dictionary  menu  and  return  to  the  main  PMS 
menu.  Before  leaving  the  dictionary,  it  gives  you  some  further  information  on  the  files 
that  exist  in  the  dictionary. 

Some  of  the  data  dictionary  files  are  not  accessible  by  you,  and  can  only  be 
accessed  by  someone  having  knowledge  of  DBASE  III  +  .  You  can  also  only  read  data 
out  of  the  dictionary"  database  personnel  must  add  new  entries  to  the  dictionary 
through  DBASE  III  +  .  The  priman-'  reason  for  this  is  the  fact  that  most  of  these  files 
contain  information  generally  only  used  by  database  personnel. 

Each  of  the  files  is  shown  below  with  a  brief  description  of  what  it  contains: 

•  CONTAINS—  Files  which  contain  elements{variables) 

•  FILE"  Describes  the  files  in  PMS. 

•  ELEMENT--  The  variable  names  and  information  about  them. 

•  PROCESSES"  The  programs  and  modules  which  process  the  elements  and 
files. 

•  PROGRAMS—  The  programs  which  control  the  operations  of  each  of  the 
menu  options  in  the  PMS  system. 

•  AUTOFILE"  Describes  the  auto  files  in  PMS. 

•  USER- Describes  the  users  of  PMS. 
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VIII.  CONCLUSION 

This  thesis  has  focused  on  application  of  a  data  base  system  for  a  Republic  of 
Korea  military  personnel  management  system.  In  order  to  reduce  expenditures  and 
manpower  for  personnel  management  and  to  increase  the  ability  of  combat  soldiers,  it 
is  ver\'  important  for  the  Korean  military  to  apply  the  computer  system  for  personnel 
management.  Since  we  use  dBASE  III+  for  application  program  in  this  thesis,  we 
should  use  relational  data  base  model.  Therefore,  we  reviewed  the  basic  knowledge 
about  a  data  base  system  in  Chapter  II  and  discussed  the  general  concept  of  relational 
model  in  Chapter  III.  After  that,  we  focused  precisely  about  the  design  problem  of  the 
relational  model  in  Chapter  IV.  In  Chapter  V,  we  discussed  the  practical  system 
analysis  and  relational  database  design  for  a  Korean  Army  personnel  management 
system.  In  order  to  maintain  and  use  the  data  base  system  effectively,  we  discussed  the 
relational  implementation  in  Chapter  VI.  Especially,  in  Chapter  VII.  processing 
procedure  to  access  actual  program  in  Appendix  A  was  shown.  When  we  construct  a 
data  file  to  access  this  program  we  should  consider  theoretical  problems  that  are 
discussed  in  Chapter  IV.  In  prototyping  personnel  data  base  in  this  thesis,  all  data 
items  such  as  career,  assignment,  education,  etc.  is  based  on  the  Korean  army 
personnel  record.  Because  of  the  military'  security  problem  we  use  artificial  sample 
data  for  prototyping. 

In  order  to  strengthen  the  readiness  of  the  Korean  military  under  the  alert  states, 
it  is  imperative  that  personnel  management  be  performed  very  efficiently.  A  most 
important  consideration  in  data  base  development  is  to  store  data  so  that  it  can  be 
used  for  a  wide  variety  of  applications  and  can  be  changed  quickly  and  easily.  In  order 
to  perform  these  functions,  the  data  should  be  independent  and  functionally  dependent 
on  key  values.  It  should  also  be  possible  to  query  the  data  base  to  satisfy  user's 
requirements  using  application  programmer  the  Database  Management  System(DBMS) 
itself  These  data  items  should  contain  useful  information  for  decision  makers  to 
analyze,  plan  and  manage  a  personnel  organization.  However,  a  data  base  is  the 
interface  between  people  and  machines.  Data  base  design  is  a  two-phased  process. 
This  thesis  examined  both  logical  and  physical  data  base  design  process,  and  this 
process  is  an  iterational  process  to  get  closer  to  an  acceptable  and  optimal  design. 
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As  it  is  discussed  in  Chapter  IV.  normal  forms  can  be  applied  to  decrease 
inefficiency  of  the  relational  data  base  model  in  the  system  design  process.  Finally,  we 
hope  this  research  and  sample  application  can  be  helpful  for  Korean  military  personnel 
management  system. 
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APPENDIX  A 
PROGRAM  STRUCTURE 


DRIVER 


UPDATE 


HUPM\IN 


-jUPEXPERT 


-jUPPRQMOT 


TABLE 


UPEDUCAT 


-iUP_M_EDl  I 


-UP    M    ED2 


MENUSCR 


-UPPROMOl 


-iUPPR0M02 


!me:;uscr 


-UP    AW    PU 


-UPAW_?U1  I 


UPAW   PU2 


-UPAW   PU3 


'MENUSCR 


nUPEVAL 


HUPCAREER 

L^  MENUSCR 


LISTING 


^L   ASSIGN 


REPORTS 


L   ALL 


-  L    E DUCAT 


-  L    PROMOT 


M  MENUSCR 


EDIT 


MENUSCR 


-lEDMAIN 


-^EDEXPER' 


Hededucat 


-JED   M    EDI 


HED   M   ED2 


Hmenuscr 


-ED   AW   PU 


EDPROMOT 


Hedpromoi 


-iEDPR0M02 


Hmenuscr    i 


-EDAW   PUl 


-EDAW    FU2 


-EDAW   PU3 


HMENUSCR 


-jEDEVAL 


Hedcareer 

-]me:uscr~ 


Die 


-IDICTI 


-  DICT2 


HDICT3 

-Idict4 


4  MEN 


USCR 
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APPENDIX  B 
PROGRAM 


1.       DRIVER.PRG 


*****3>c7<c*yc*****:<c****5*r***5lt**yr*******:^7^5^*:^******5lc*****************5le*?lc***7it 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


:  DRIVER.PRG 

;KIM,       SAM   NAM 

;31    OCT   86 

:This  is  the  DRIVER  module  for  the  entire  system. 

*  It  queries  the  user  for  task  selection  and  calls 

*  the  correct  module  to  service  that  request. 

*  When  control  is  returned  from  the  caliinq  module 

*  the  user  is  asked  if  more  information  is  required. 

*  If  yes,   then  the  process  is  repeated,   else,   the 

*  program  terminates. 

*  Called  by    :  DRIVER  is  called  at  system  startup 

*  Modules  called  :MENUSCR, TABLE, LISTING, REPORTS , UPDATE , EDIT, DICT 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 
'^  today:  holds  date 

*  Local   :  none  - 

*  Set  up  loop  for  presenting  menu. 

tIc  tIc  *  tIc  *  ^  T^c  ;*:  ^  tIt  ^ir /^t  A  7*:  7^  X  *  ^ir  :^  7c  X  A  :i'c  ^ir  x  X  :^  ?c  X /'c  T*:  t'c  tIc  7^ 

*Close  all  open  files 
CLEAR  ALL 

■k Set  working  working  environment 

SET  TALK  OFF 
SET  ESCAPE  OFF 
SET  BELL  OFF 
SET  HEADING  OFF 
SET  HELP  OFF 
SET  MENU  OFF 
SET  SAFETY  OFF 
SET  STATUS  OFF 

* Create  underline  variable,  Uline. 

uline=REPLICATE  ("_",  80) 

■k Create  memory  variable  for  today's  date. 

today=DATE() 

*  This  sets  up  the  CRASH.TXT  file  which  records  all  actions  so 

*  that  if  the  system  crashes,   the  data  base  can  be  recreated.  This 

*  file  is  deleted  if  the  system  terminates  normally. 

SET  ALTE  TO  CRASH 
SET  ALTE  ON 
DO  WHILE  .T. 

*  DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  DO  FOREVER 

*  The  DO  WHILE  will  be  terminated  by  an  EXIT  command 

*  Clear  the  screan  and  display  the  main  menu 
CLEAR 

DO  MENUSCR 

(='2,11  SAY  "   OFFICER   PERSONNEL  MANAGEM" 

@  2,62  SAY  "E  N  T" 

@  6,36  SAY  "MENU" 

@  19,33  SAY  "INFORMATION" 

@  8,12  SAY  "A.  PERSONNEL  ALLOTMENT  TABLE." 

(§9,12  SAY  "B.  LISTING." 

d  10,15  SAY  "  Any  query  that  requires  a  listing  or  information" 

(§  11,12  SAY  "C,  REPORTtpersonal 'record  card)." 

(§  12,12  SAY  "D.  UPDATE.^' 

@  13,12  SAY  "E.  EDIT." 

(§  14,12  SAY  "F.  DICTIONARY." 
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(?  15,12  SAY  "G.  CHANGE  DATE." 
(?  16,12  SAY  "X.  EXIT." 
@  20,8  SAY  "DATE         TIME" 
@  20,55  SAY  "UPDATED  BY" 
(§21,5  SAY  today 
(§  21,19  SAY  TIMEO 
*  (a  21,55  SAY  gname 

(§  23,10  SAY  "  [  Enter  selection  (  A  -  G,  or  X  to  Exit  ) 
DO  VWILE  .T. 
1=0 

DO  WHILE  1=0 
i=INKEY() 

@  21,19  SAY  TIMEO 
(§  23,54  SAY  "" 
IF  UPPER(CHR(i))$"A3CDEFGX" 

EXIT 
ENDIF 
i=0 
ENDDO 

@  23,54  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"Gq" 

EXIT 
ENDIF 

SET  COLOR  TO  N/W 
(§  19,33  SAY  "INFORMATION" 
(?  15,12  SAY  "G.  CHANGE  DATE." 

SET  COLOR  TO  W/N  • ■   • 

@  21,5  GET  today 
READ 

(§21,5  SAY  todav 
@  19,33  SAY  "INFORMATION" 
(?  15,12  SAY  "G.  CHANGE  DATE." 
(?  23,54  SAY  "  " 
ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
RELEASE  i, today 
SET  TALK  ON 
SET  ESCAPE  ON 
SET  BELL  ON 
SET  HEADING  ON 
SET  HELP  ON 
SET  MENU  ON 
SET  SAFETY  ON 
SET  STATUS  ON 
CLEAR 
RETURN 
CASE  CHR(i)$"Aa" 

DO  TABLE 
CASE  CHR(i)$"Bb" 

DO  LISTING 
CASE  CHR(i)$"Cc" 

DO  REPORTS 
CASE  CHR(i)$"Dd" 

DO  UPDATE 
CASE  CHR(i^$"Ee" 

DO  EDIT  ■ 
CASE  CHR(i)$"Ff" 
DO  DICT 
ENDCASE 
ENDDO 

SET  ALTE  OFF 
CLEAR  ALL 
CLOSE  ALTE 
ERASE  CRASH.TXT 

X when  done,  return  to  main  menu 

RETURN 
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a.  MENUSCR.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 

*  Modules  called 

*  Variables  used 


MENUSCR.PRG 

KIM,   SAM  NAM 

30  OCT  86 

Menu  screen 

None 

Local   :  none 

*  Grobal  :  today  :  holds  date 

*  Set  up  presenting  menu. 

:<;  *  :*:  y^  5"^  7*:  ^ic  ;^  X  7t  ^ir  ^ic  X  jit  X  t:  9:  T^c  7c  X  :^  7C  X  X  X  7T  x  X  3'c  X  7!^  7^  :^  :*:  ^ic  :*:  :'c  ^ 

d  1,9  TO  3,69 

@  4,1  TO  24,77  DOUBLE 

@  6,3  TO  17,75 

@  5,30  TO  7,46  DOUBLE 

(a  6,31  SAY  SPACE (15) 

(a  19,3  TO  22,75 

(?  18,30  TO  20,46  DOUBLE 

(a  19,31  SAY  SPACE (15) 

(a  5,2  SAY  REPLICATE (CHR(176), 28) 

(a  6,2  SAY  CHR(176' 

@  7,2  SAY  CHR(176' 

(a  8,2  SAY  CHR(176 

(a  9,2  SAY  CHR(176 

(§  10,2  SAY  CHR(176 

@  11 

(a  12 

(a  13 

(a  14 

(§  15 

(a  16 

(a  17 

(a  18 


(a  19 

(a  20 

(§  21 

(a  22 

@  23 

(a  22 

(a  21 

(?  20 

(§  19 

(a  18 

(a  17 

(a  16 

@  15 

(a  14 

(a  13 

(a  12 

(a  11 

(a  10 


2  SAY  CHR(176 

2  SAY  CHR(176' 

2  SAY  CHR(176' 

2  SAY  CHR(176 

2  SAY  CHR(176' 

2  SAY  CHR(176 

2  SAY  CHR(176 

2  SAY  REPLICATE (CHR( 176), 28) 

2  SAY  CHR(176' 

2  SAY  CHR(176' 

2  SAY  CHR(176' 

2  SAY  CHR(176 

2  SAY  REPLICATE(CHR(176),75) 

76  SAY  CHR(1''6' 

76  SAY  CHR(176' 

76  SAY  CHR(176 

76  SAY  CHR(176' 

47  SAY  REPLICATE(CHR(176),30) 

76  SAY  CHR(176' 


76  SAY  CHR(176 

76  SAY  CHR(176' 

76  SAY  CHR(176' 

76  SAY  CHR(176' 

76  SAY  CHR(176 

76  SAY  CHR(176' 

76  SAY  CHR(176' 
@  9,76  SAY  CHR(176 
(a  8,76  SAY  CHR  176 
(a  7,76  SAY  CHR(176 
(§6,76  SAY  CHR(176' 
(a  5,47  SAY  REPLICATE  (CHR(  176)  ,30) 
(a  19,33  SAY  "INFORMATION" 
(a  20,8  SAY  "DATE         TIME" 
(a  20,55  SAY  "UPDATED  BY" 
(a  21,5  SAY  today 
(a  21,19  SAY  TIMEO 
*(a  21,52  SAY  gname 
RETURN 
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2.       TABLE.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


(?  19,33  SAY 

@  10,18  SAY 

(§  11,13  SAY 

@  12,18  SAY 

(?  14,18  SAY 

(§  16,18  SAY 


!  TABLE. FRG 

iKIM,   SAM  NAM 

;1  DEC  36 

[This  is  the  DRIVER  module  for  personnel  allotment. 

*  *         When  control  is  returned  from  the  called  module 

*  the  user  is  asked  if  more  information  is  required 

*  and  the  process  is  repeated,  or  control  is  passed 

*  back  to  the  DRIVER  module. 

*  Called  by    :  DRIVER 

*  Modules  called  a-IENUSCR 
'^   Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  allotment  table. 

CLEAR 

DO  WHILE  .T. 
CLEAR 

DO  MENUSCR 

@2, 15  SAY  "PERSONNEL   ALLOTMENT" 
@  6,35  SAY  "TABLE" 

"INFORMATION" 
"COMPANY  GRADE  OFFICER:" 
"FIELD  GRADE  OFFICER  :" 
"GENERAL  GRADE  OFFICER:" 
"   TOTAL  :" 

"*-^-^*'   X.  Return  to  main  menu  '^*'^**" 
@  20,8  SAY  "DATE         TIME" 
(?  20,55  SAY  "UPDATED  BY" 
(§21,5  SAY  today 
(§  21,19  SAY  TIMfiO 
^   (3  21,55  SAY  gname 
(§  23,10  SAY  "  [       Enter  X  to  Exit  :  :  ]" 

USE  member  INDEX  member 

FIND  warrent  officer 

COUNT  WHILE  ranks  =  "warrent  officer"  TO  xxi 

FIND  2nd  lieutenant 

COUNT  WHILE  ranks  =  "2nd  lieutenent"  TO  xx2 

FIND  1st  lieutenent 

COUNT  WHILE  ranks  =  "1st  lieutenent"  TO  xx3 

FIND  captain 

COUNT  WHILE  ranks  =  "captain"  TO  xx4 

FIND  major 

COUNT  WHILE  ranks  =  "major"  TO  xx5 

FIND  lieutenent  colonel 

COUNT  WHILE  ranks  =  "lieutenent  colonel"  TO  xx6 

FIND  colonel 

COUNT  WHILE  ranks  =  "colonel"  TO  xx7 

FIND  brigader  general 

COUNT  WHILE  ranks  =  "brigader  general"  TO  xx8 

FIND  major  general 

COUNT  WHILE  ranks  =  "  major  general"  TO  xx9 

FIND  lieutenent  general 

COUNT  WHILE  ranks  =  "lieutenent  general"  TO  xxlO 

FIND  general 

COUNT  WHILE  ranks  =  "general"  TO  xxll 

company  =  xxl  +  xx2  +  xx3  +  xx4 

field  =  xx5  -t-  Xx6  +  xx7 

gener  =  xx8  +  xx9  +  xxlO  +  xxll 

addsum  =  company  +  field  +  gener 

(§  10,45  SAY  company 

(?  11,45  SAY  field 

@  12,45  SAY  gener 

@  14,45  SAY  addsum 

120 


DO  ^^ILE  .T. 
i=0 

DO  ^VHILE  i=0 
i=IMK5y() 

(§  21,19  SAY  TIMEO 
(?  23,54  SAY  "" 
IF  UPFER(CHR(i))$"X" 

EXIT 
END  IF 
i=0 
ENDDO 

(§  23,54  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"  " 

EXIT 
ENDIF 
READ 
ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 

CLOSE  DATABASES 
RETURN 
ENDCASE 
ENDDO 
■k when  done, return  to  main  menu 

3.   LISTING.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


LISTING.PRG 

PARK,   JAE  BOCK 

1  nov  86 

This  is  the  DRIVER  module  for  the  listing  system. 

*  "  It  queries  the  user  for  task  selection  and  calls  the 

*  required  modules. 

*  When  control  is  returned  from  the  called  module, 

*  the  user  is  asked  if  more  information  is  required 

*  and  the  process  is  repeated,   or  control  is  passed 
'^             back  to  the  DRIVER  module. 

*  Called  by    :  DRIVER 

*  Modules  called  :MENUSCR,   L_ALL,   L_ASSIGN,   L_EDUCAT,   L_PROMOT 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

■k:kir-k'ki!'k*-kir'kir-k-ki';7r:kir:k7rT;:k'k7r:k-kk-k9^:k7r-k'k-k'kir:k-k-kirir-k-k-ki<ir9riri^9^ 

*  Set  up  loop  for  presenting  menu. 

CLEAR 

DO  WHILE  .T. 

CLEAR 

DO  MENUS CR 

(§2,32  SAY  "LISTING" 

(§6,34  SAY  "SUBMENU" 

(§  19,33  SAY  "INFORMATION" 

(§  8,12  SAY  "A.  List  all  officers." 

(§9,12  SAY  "B.  List  all  new  officers  for  assignment." 

(§  10,12  SAY  "C.  List  all  officers  educated.  " 

(§  11,12  SAY  "D.  List  all  officers  for  promotion  test." 

(§  12,12  SAY  "E.  Change  date" 

(§  14,12  SAY  "X.  Return  to  main  menu" 

(§20,8  SAY  "DATE         TIME" 

(§  20,55  SAY  "UPDATED  BY" 

(§21,5  SAY  today 

(§  21,19  SAY  TIMEO 
*   (§  21,55  SAY  gname 

(§  23,10  SAY  "  [  Enter  selection  (  A  -  E,  or  X  to  Exit  )  :  :  ]" 

DO  WHILE  .T. 

121 


i=0 

DO  WHILE  i=0 
i=INKEY() 

(§  21,19  SAY  TIMEO 
&   23,54  SAY  "" 
IF  UPPER (CKR(i))$"ABCDEX" 

EXIT 
ENDIF  ... 

i=0 
ENDDO 

(§  23,54  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"Ee" 

EXIT 
ENDIF 

SET  COLOR  TO  N/W 
(?  19,33  SAY  "INFORMATION" 
(?  12,12  SAY  "E.  CHANGE  DATE" 
SET  COLOR  TO  W/N 
(§21,5  GET  today 
READ 

(§21,5  SAY  today 
(§  19,33  SAY  "INFORMATION" 
(§  12,12  SAY  "E.  Change  date" 
(§  23,54  SAY  "  " 
ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx"    .  ... 

'CLEAR 
RETURN 
CASE  CHR(i)$"Aa"  . 

DO  L_ALL 
CASE  CHR(i)$"Bb" 

DO  L_ASSIGN 
CASE  CHR(i)$"Cc" 

DO  L_EDUCAT 
CASE  CHR(i)$"Dd" 
DO  L_PROMOT 
ENDCASE 
ENDDO 

■k when  done,  return  to  main  menu 

RETURN 

a.  L.ALL.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


;L_ALL.PRG 
;KIM,   SAM  NAM 
15  DEC  36 
;This  module  provides  the  listing  service  required 

*  *  to  list  all  members. 

*  Called  by    :  LISTING 

*  Modules  called 

*  Variables  used 

*  Global 

*  Local 


none 

none 

park  :  holds  values  of  user  answer. 


*  Set  up  loop  for  presenting  menu. 

CLEAR 

SET  TALK  OFF 

park  =  "x" 

park  =  SPACE(l) 

©15,5  SAY  "Send  data  to  printer  ?  (Y/N)"  GET  park 

READ 

SELECT  1 

USE  main  INDEX  MAIN 

SELECT  2 

USE  member 

JOIN  WITH  main  TO  all  FOR  sns  =  A->sn  ; 

FIELDS  ranks , sns , A->name , A->c_type , org_branch,p_order 
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USE  all 

IF  park  =  "Y" 

SET  PRINT  ON 

LIST  ranks, sns, name, c_type 

SET  PRINT  OFF 
ELSE 

LIST  ranks, sns, name, c_type 
ENDIF 
WAIT 
CLOSE  DATABASES 

* when  done,  return  to  main  menu. 

RETURN 

b.  L_ASSIGN.PRG 


*  Module  name 
"^   Author 

*  Date 

*  Purpose 


L_ASSIGN.PRG 

PARK,   JAE  BOCK 

1  DEC  86 

This  is  the  LISTING  module  for  the  listing  system. 

*  *  This  module  is  used  who  the  user  requires  a  new 

*  officers  list  for  assignment. 

*  Called  by    :  LISTING 

*  Modules  called  : 

*  Variables  used  : 

*  Global  :  today:  holds  date 

*  Local   :  rank  :  holds  the  values  of  the  user  input, 

*  accept  the  military  rank. 

*  order:  holds  the  values  of  the  user  input, 

*  accepts  the  personnel  order. 

*  Set  up  loop  for  presenting  menu. 

CLEAR 

USE  all  INDEX  p_all 

rank  =  "x" 

order  =  "x" 

DO  WHILE  order  #  "  "  .OR.  rank  #  "  " 

* Find  out  the  personnel  order  and  rank. 

CLEAR 

(§  2,1  SAY  "LIST  ALL  NEW  OFFICERS'  RECORD" 

(?  2,60  SAY  today 

(a  2,70  SAY  TIME() 

@  3,0  SAY  ULINE 

@  5,0  CLEAR 

■k Get  proposed  pesonnel  order  and  rank. 

order  =  SPACE(20) 

rank  =  SPACE (20) 

(§15,5  SAY  "List  for  what  personnel  order(  or  press  RETURN; 

to  exit)" 

@  16,5  SAY  "(  e.g  >   86-35  ARMY  )"  GET  order 

READ 

§  17,5  SAY  "List  for  what  rank   (or  press  RETURN  to  exit)" 

(?  18,5  SAY  "(e.g >  1st  lieutenent)"  GET  rank 

READ 

order  =  order  +  rank 

order  =  lower(order) 

SEEK  order 

DO  CASE 

CASE  order  =  "  " 

CLEAR 

CASE  FOUND  0 

@  5,0  CLEAR 

STORE  "  "  TO  YN, printer 

(§  15,15  SAY  "Send  to  printer  ?(Y/N).    "  GET  YN  PICT  "?" 

READ 

■f^ Set  up  printer  macro. 

IF  YN  =  "Y" 
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Printer  =  "TO  PRINT" 
END  IF 

REPORT  FORM  r_assign  FOR  p_crder  +  ranks  =  order  Sprinter 
WAIT 
CASE  .NOT.  FOUND 0 
CLEAR 
(a  17,5  SAY  "  There  is  no  "  +  order 

(a  24,5  SAY  "PRESS  ANY  KEY  TO  TRY  AGAIN " 

?  CHR(7) 
WAIT  "  " 
ENDCASE 
ENDDO 

^ When  done,  return  to  listing  menu. 

RETURN 

c.  L_EDUCAT.PRG 

*  5^  5ic  Tic  *  Tic  :«c  :*r  jic  :V  Tic  jic  7>c  Tif  :i^  5ic  7^  5ir  rir  *  *  •  3»r  Tit  Tir  :^  5ic  X  7>f  yc  A  jic  5ic  jic  Tit  5>C  Tie  Tie  Tic  ^ir  5^  * 


*  Module  name 
'^  Author 

*  Date 

*  Purpose 


;L_EDUCAT.PRG 
;PARK,   JAE  BOCK 
1  DEC  86 
;This  is  the  LISTING  module  for  the  listing  system. 

*  This  module  is  used  when  the  user  requires  the  list 

*  of  officers  educated  in  a  particular  courses. 
'^  Called  by    :  LISTING 

*  Modules  called  :none 

*  Variables  used  : 

*  Local   :  names  :  holds-  the  value  of  the  user  input-. 

*  acceptable  values  :  military  education  course  name 

*  Global  :  today :  holds  date 

Tic:'c:^T'c:^TicTicTic7CTic:fcT^7t7CT'cTicT*rTic:fc7CT^7rTrx^:^Tic:^TicT^T'cTicTicT'cT'cTic:'c:^T^TlcTic7t^ 

*  Set  UD  loop  for  presenting  menu. 

CLEAR 

USE  j_educat  INDEX  j_educat 

names="x" 

DO  WHILE  names  #  "  " 

■k Find  out  what  course  name  to  list. 

CLEAR 

(§2,60  SAY  today 

(§2,70  SAY  TIMEt) 

(§3,0  SAY  ULINE 

p 

* Get  proposed  course  name. 

names  =  SPACE (20) 

(§15,5  SAY  "List  for  what  course  name(  or  press  RETURN; 

to  exit)" 

@  16,5  SAY  "(  e.g  --MNFANTRY  O.A.C#234  )"  GET  names 

READ 

names  =  lower (names) 

SEEK  names 

DO  CASE 

CASE  names  =  "  " 

CLEAR 

CASE  FOUND  0 

(§5,0  CLEAR 

STORE  "  "  TO  YN, printer 

(§  15,15  SAY  "Send  to  printer  ?(Y/N).    "  GET  YN  PICT  "!" 

READ 

* Set  up  printer  macro. 

IF  YN  =  "Y" 

Printer  =  "TO  PRINT" 

END  IF 

REPORT  FORM  r_educat  FOR  cname  =  names  Sprinter 

WAIT 
CASE  .NOT.  FOUND 0 

CLEAR 

(§17,5  SAY  "  There  is  no   "  +  names 

(§  24,5  SAY  "PRESS  ANY  KEY  TO  TRY  AGAIN " 
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?  CHR(7) 
WAIT  '^  '' 
ENDCASE 
ENDDO 

■k When  done,  return  to  listing  menu. 

RETURM 

d.  L_PROMOT.PRG 

**7>:***xA:>:******A5>:****A****  A  AA***:^  ?*:****************  Ax:<c*  AAA********  A* 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


I 


L_PROMOT . PRG 
PARK,   JAE  BOCK 
1  DEC  86 
^ .This  is  the  LISTING  module  for  the  listing  system. 

*  This  module  is  used  when  the  user  requires  the 

*  officers  list  for  promotion  test. 

*  Called  by    :  LISTING 

*  Modules  called  : 

*  Variables  used  : 

*  Local   :  rank:  holds  the  value  of  the  user  input, 

*  acceptable  values:  military  rank. 

*  year:  holds  the  value  of  the  user  input, 

*  acceptable  values:  promotion  year. 

*  Global  :  today  :  holds  the  date 

***********************7C********************************************** 

*  Set  up  loop  for  presenting  menu. 
***************************^********:^********************************* 

CLEAR  .        •  • 

USE  all  INDEX  r_all 

rank  =  "x" 

G  3  f  S  —  "  v" 

0  WHILE  rank  tt  "  "  .OR.  years  #  "  " 

* Find  out  rank  and  promotion  year. 

CLEAR 

(§2,1  SAY  "LIST  ALL  OFFICERS  FOR  PROMOTION  TEST." 

(§2,60  SAY  today 

@  2,70  SAY  TIME() 

@  3,0  SAY  ULINE 

7 

@  5,0  CLEAR 

* Qet  proposed  and  rank. 

rank  =  SPACE (20) 
years  =  SPACE (2) 
@  15,5  SAY  "List  for  what  rank   (or  press  RETURN  to  exit)" 

(§16,5  SAY  "(e.g >  1st  lieutenent)"  GET  rank 

READ 

(§17,5  SAY  "What  is  a  promotion  year?  (or  press  RETURN  to  exit)" 

(§  13,5  SAY  "(e.g >  82)"  GET  years 

READ 

rank  =  LOWER(rank) 

years  =  LOWER(years) 

SEEK  rank 

DO  CASE 

CASE  rank  =  "  "  .OR.  years  =  "  " 

CLEAR 

CASE  FOUND  0 

(§5,0  CLEAR 

STORE  "  "  TO  YN, printer 

(§  15,15  SAY  "Send  to  printer  ?(Y/N).    "  GET  YN  PICT  "!" 

READ 

* Set  up  printer  macro. 

IF  YN  =  "Y" 

Printer  =  "TO  PRINT" 

END  IF 

REPORT  FORM  r_promote  FOR; 
ranks  =  rank  .AND.  SUBSTR(p_order , 1 ,2)  <=  years  Sprinter 

WAIT 
CASE  .NOT.  FOUND 0 

CLEAR 
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<a  17,5  SAY  "  There  is  no  "  +  rank 

(3  24,5  SAY  "PRESS  AMY  KEY  TC  TRY  AGAIN " 

?  CHR(7) 

WAIT  ■'  •' 
ENDCASE 
ENDDO 

* When  done,  return  to  listing  menu. 

RETURN 

4.        REPORTS.PRG 

*  Module  name  :REPORTS.PRG 

*  Author  :PARK,   JAE  BOCK 

*  Date  :1  DEC  86 

*  Purpose  :This  is  the  DRIVER  module  for  the  report  system. 

*  This  module  is  used  when  the  user  requires  the 

*  personnel  record  card. 

*  Called  by    :  DRIVER 

*  Modules  called  :  none 

*  Variables  used  : 

*  Global  :  today:  holds  date 

*  Local   :  none 

*  :fc  X  3>:  :fc  7C  :*c  x  :*t  :*c  7*;  >*:  ><>  :*c  X  *  X  7>r  :Ar  X  7k  X  X  5*:  7*:  tV  5<:  jic  t":  T*:  :'c  ri*:  :^  jit  :'c  :*:  7*:  X 

*  Set  up  loop  for  presenting  menu. 

Tie  7*:  7k  Tic  7k  7t  7k  7it  Tic  *  tV  7>:  Tt:  Tit  7*:  7ic*  ^  7>c  7ic  7*:^  T^r  Tic  yt  7*r  ;/ir?c  Tlf  7*r  Tic  :^  7>C  7^  7>r  7lr  X  *  7ic  7ic  :<r  7*:  Tic  *  7^ 

CLEAR 

USE  all  INDEX  all 

msn  =  "x" 

DO  WHILE  msn  #  "  " 

■k Find  out  service  number.  - 

CLEAR 

@  2,1  SAY  "PERSONNEL  RECORD  CARD." 

(a  2,60  SAY  today 

(§2,70  SAY  TIME() 

(3  3,0  SAY  ULINE 

■? 

§  5,0  CLEAR 

■k Qet  proposed  service  number. 

msn  =  SPACE(8) 

@  15,5  SAY  "List  for  what  service  number   (or  press  RETURN  to  exit)" 

@  16,5  SAY  "(e.g  >  21554)        "  GET  msn 

READ 

msn  =  LOWER(msn) 

SEEK  msn 

DO  CASE 

CASE  msn  =  "  " 

CLEAR 
CASE  FOUND  0 

(3  5,0  CLEAR 

ACCEPT  "Send  to  printer  ?(Y/N)."  TO  printer 

7k Set  up  printer  . 

IF  printer  =  ^Y^ 
SET  PRINT  ON 

END  IF 

CLEAR 

REPORT  FORM  rreport  FOR  sns  =  msn 

WAIT  "  " 

USE  EXPERT 

@  24,5  SAY  "EXPERT  TITLE  " 

LIST  expertitle  FOR  sn=msn 

WAIT  "  ^ 

USE  careers  INDEX  careers 

SEEK  msn 

REPORT  FORM  r_career  FOR  sn=msn 

USE  p_eval  INDEX  p_eval 

SEEK  msn 
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REPORT  FCRI'I  r_eval  FOR  sn=msn 

WAIT  "  " 

SELECT  1 

USE  rank 

SELECT  2 

USE  crcmote  INDEX  promote 

JOIN*  V?ITH  rank  TO  temp  FOR  p_order=A->p_order  FIELDS  A->ranks,; 
A-> tdate ,p_order , sn 

USE  temp 

INDEX  ON  p_order  TO  p_temp 

CLEAR 

@  5,5  SAY  "RANK  PROMOTION  PROMOTION" 

(§6,5  SAY  "  DATE  ORDER  " 

LIST  FOR  sn=msn 

CLOSE  DATABASES 

WAIT  "  " 

SELECT  3 

USE  awardpun 

SELECT  4 

USE  a_p_mn  INDEX  a_p_mn 

JOIN  WITH  awardpun  TO  temp  FOR  p_order=C->p_order  FIELDS  C->kind, ; 
p_order , C-> tdate , sn 

USE  temp 

INDEX  ON  p_order  TO  p_temp 

CLEAR 

(§5,5  SAY  "   KIND  OF  AWARD  PERSONNEL  ORDER    DATE" 

(§  6,5  SAY  "   AND  PUNISHMENT  " 

LIST  FOR  sn=msn 

WAIT  "  " 
CASE  .NOT.  FOUND 0 

CLEAR 

(§17,5  SAY  "  There  is  no  "  +  msn 

(§  24,5  SAY  "PRESS  ANY  KEY  TO  TRY  AGAIN " 

?  CHR(7) 

WAIT  "  " 
END CASE 
ENDDO 

* When  done,  return  to  listing  menu. 

RETURN 

5.       UPDATE.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


UPDATE . PRO 

KIM,       SAM  NAM 

27    oct   36 

This  is  the  DRIVER  module  for  the  update  function. 

*  '  It  sets  up  the  main  update  menu,   accepts  input 
'^  from  the  user  and  calls  the  required  modules. 

*  When  control  is  returned  from  the  called  module, 

*  the  user  is  asked  if  more  information  is  required 

*  and  the  process  is  repeated,   or  control  is  passed 

*  back  to  the  DRIVER  module. 

*  Called  by      :  DRIVER 

*  Modules  called  :MENUSCR,   UPMAIN,   UPEXPERT,   UPEDUCAT ,   UPPROMOT, 

*  UP_AW_PU,   MAINTAIN,   UPEVAL ,   UPCAREER 

*  Variables  used  : 

'^        Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  UD  loop  for  presenting  menu. 

CLEAR 

DO  WHILE  .T. 

CLEAR 

DO  MENUSCR 

(§2,14  SAY  "UPDATE    PERSONNEL   RECORDS" 
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©6,34  SAY  "SUBMENU" 

?>  19,33  SAY  "INFCPJIATION" 

@  9,5  SAY  "A.  Add  new  officer  members" 


'B.  Add  excert  members' 
'C.  Add  military  education" 
'  results'- 

'D.  Add  recent  promotion  members" 
'E.  Add  award  and  ounishment  records" 
F.  Add  performance' evaluation" 


t|  10,5  SAY 
<?  11,5  SAY 
(5  12,3  SAY 
@  13,5  SAY 
(§14,5  SAY 
(§9,42  SAY 

(§  10,45  SAY  "  recor'ds" 
(§  11,42  SAY  "G.  Add  assignment  records" 
(§  13,42  SAY  "I.  Change  date" 
(§  14,42  SAY  "X.  Return  to  main  menu" 
(§20,8  SAY  "DATE         TIME" 
(§  20,55  SAY  "UPDATED  BY" 
(§21,5  SAY  today 
(§  21,19  SAY  TIMEO 
^(§  21,52  SAY  gname 

(§  23,10  SAY  "[Enter  selection  (A  -  I,  or  X  to  return  to  main" 
(§  23,57  SAY  "  menu)  :  :  ]" 
DO  WHILE  .T. 
i=0 

DO  WHILE  i=0 
i=INKEY() 

(§  21,19  SAY  TIMEO 
(§  23,65  SAY  "" 
.  IF  UPPER(CHR(i))$"ABCDEFGIX"   ■ 
EXIT 
ENDIF 
1=0 
ENDDO 

(§  23,65  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"ii" 

EXIT 
ENDIF 

SET  COLOR  TO  N/W 
(§  19,33  SAY  "INFORMATION" 
(§  13,42  SAY  "I.  CHANGE  DATE" 
SET  COLOR  TO  W/N 
(§21,5  GET  today 
READ 

(§21,5  SAY  today 
(§  19,33  SAY  "INFORMATION" 
(§  13,42  SAY  "I.  Change  date" 
(§  23,65  SAY  "  " 
ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 

DO  maintain 
RETURN 
CASE  CHR(i)$"Aa" 

DO  UPMAIN 
CASE  CHR(i)$"Bb" 

DO  UPEXPERT 
CASE  CHR(i)$"Cc" 

DO  UPEDUCAT 
CASE  CHR(i)$"Dd" 

DO  UPPROMOT 
CASE  CHR(i)$"Ee" 

DO  UP_AW  PU 
CASE  CHR(ir$"Ff" 

DO  UPEVAL 
CASE  CHR(i)$"Gg" 
DO  UPCAREER 
END CASE 
ENDDO 

ir when  done, return  to  main  menu 

RETURN 
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a.  MAINTAIN.PRG 


"^   Module  name 

*  Author 

*  Date 

*  Purpose 


: MAINTAIN.PRG 
jKIM,   SAM  NAM 
1  DEC  86 
:This  is  the  data  file  maintenance,  used  for 

*  *         updating  and  editing. 

*  Called  by    :  UPDATE,   EDIT 

*  Modules  called  :  none 

USE  kirn 
DELETE  ALL 
PACK 

USE  promote  INDEX  promot 
i  =  sn 

field  =  p_order 
DO  WHILE  .not.  EOF() 
X  =  i 
y  =  field 
1  =  sn 

fieldd  =  p_order 
IF  i  =  X 

string  =  SUBSTR(fieldd,l,2) 
fields  =  SUBSTR(y,l,2) 
IF  string  >  fields 
field  =  p_order 
END  IF 
END  IF 
IF  i  <>  X 
USE  kirn 
-  APPEND  BLANK 

REPLACE  sns  WITH  x 
REPLACE  porder  WITH  y 
USE  promote  INDEX  promot 
field  =fieldd 
ENDIF 

LOCATE  FOR  sn  =  i  .AND.  p_order  =  fieldd 
SKIP 
ENDDO 
USE  kim 
APPEND  BLANK 
REPLACE  sns  WITH  i 
REPLACE  porder  WITH  field 
SELECT  1 
USE  kim 
SELECT  2 

USE  rank  INDEX  rank 
JOIN  WITH  kim  TO  member  FOR  p_order  =  A->porder  ; 

FIELDS  A->sns ,p_order, ranks , tdate 
SELECT  3 

USE  main  INDEX  MAIN 
SELECT  4 
USE  member 
JOIN  WITH  main  TO  all  FOR  sns  =  C->sn  ; 

FIELDS  ranks , sns ,C->name ,C->c_type ,org_branch,p_order, ; 
tdate , C->born_date , C->born_place 
USE  all 
REINDEX 

CLOSE  DATABASES 
RETURN 
b.  UPMAIN.PRG 


*  Module  name 

*  Author 
'^  Date 

*  Purpose 


UPMAIN.PRG 

PARK,   JAE  BOCK 

22  NOV  86 

This  is  the  UPDATE  module  for  updating  new  member. 


*  It  sets  up  the  add  new  officer  members  menu, 
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*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  frc'm  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UPDATE  module. 

*  Called  by      :  UPDATE 

*  Modules  called  rSCREENl 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  usei  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  UD  loop  for  adding  new  officer  members. 

*  :*c  jif  A  *  X  7^  :^  X  X  :^  :*:  r'c  K  :*:  *  9r  :«c  7*:  ^  T^c  X  :*c  X  ^c  A  X  X  T^c  X  :Ar  T^c  X  :*:  t't  yc  A  t'^  7>c  A  5*r  5I?  ^ 

USE  main  Index  main 

sns  ~  " x" 

DO  WHILE  sns  #  "  " 

CLEAR 

@  2,1  SAY  "Add  new  officer  members" 

(§2,60  SAY  today 

@  2,70  SAY  time!) 

@  3,0  SAY  ULINE 

* Qet  proposed  service  number. 

sns  =  SPACE (8) 

@  15,5  SAY  -"Enter  service  number  (•  or  press  RETURN; 
.  to  exit)"  GET  sns 
READ 

* Check  to  see  if  service  number  already  exists. 

sns  =  LOWER(sns) 
-  SEEK  sns 
DO  CASE 

* If  user  did  not  enter  a  service  number, 

'^ clear  the  screen  and  return  to  UPDATE  menu. 

CASE  sns  =  "  " 
CLEAR 

■k If   service  number  already  exists, 

■k notify  user  and  allow  another  try. 

CASE  FOUND  0 

@  20,10  SAY  sns  +  "already  exists" 

?  CHR(7) 

WAIT 

* If  service  number  not  already  taken, 

* let  user  add  it. 

CASE  .NOT.  FOUND 0 
APPEND  BLANK 
REPLACE  sn  WITH  sns 
SET  FORMAT  TO  screenl 
READ 

SET  FORMAT  TO 
ENDCASE 
ENDDO(While  user  does  not  enter  blank  for  service  number.) 
REINDEX 

■k Return  tO  UPDATE  menu. 

RETURN 

c.  UPEXPERT.PRG 

***ki<i(i<*kir:k-k*kkkkkk*kkkkkkkkkkkkk-kirkkkk-kki^-k*i(*ir*ki(i^**-k-k-k*ir**-kie-fK*irk 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


UPEXPERT.PRG 

PARK,   JAE  BOCK 

22  NOV  86 

This  is  the  UPDATE  module  for  adding  expert  to  the  EXPERT 

*  database  file.  It  sets  up  the  add  expert  members  menu, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UPDATE  module. 
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*  Called  by      :  UPDATE 

*  Modules  called  :none 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  adding  new  officer  members. 

sns  ""  " x" 

DO  WHILE  sns  #  "  " 
CLEAR 

(§2,1  SAY  "Add  expert  members" 
(§2,60  SAY  today 
(§2,70  SAY  TIKEt) 
(§  3,0  SAY  ULINE 
■? 

■k Qet  proposed  service  number. 

sns  =  SPACE (8) 

(§15,5  SAY  "Enter  service  number  (  or  press  RETURN; 

to  exit)"  GET  sns 

READ 

■k Check  to  see  if  service  number  already  exists. 

USE  main  INDEX  main 
sns  =  LOWER(sns) 
" SEEK  sns 
DO  CASE 

* If  user  did  not  enter  a  service  number, 

* clear  the  screen  and  return  to  UPDATE  menu. 

CASE  sns  =  "  " 
CLEAR 

■k If  service  number  does  not  exist, 

■k notify  user  and  allow  another  try. 

CASE  .NOT,  FOUND 0 

(§  20,10  SAY  sns  +  "does  not  exist" 

?  CHR(7) 

WAIT 

• T£  service  number  already  exists  in  the  MAIN  file, 

k checlc  to  see  if  service  number  and  expert  title  already 

k exists  in  the  EXPERT  file. 

CASE   FOUND () 

USE  expert  INDEX  expert 

k 3gt  up  loop  for  adding  exoert  titles. 

ttitle  =  "x" 
DO  WHILE  ttitle  #  "  " 
CLEAR 

(§2,1  SAY  "Add  exoert  members" 
(§2,60  SAY  today 
(§2,70  SAY  TIME() 
(§  3,0  SAY  ULINE 

7 
7 

k Qet  proposed  expert  title 

ttitle  =  SPACE(20) 

(§15,5  SAY  "Enter  expert  title  (or  press  RETURN  to; 
exit)"  GET  ttitle 
READ 

*--   Check  to  see  if  service  number  already  exists. 
SEEK  sns 
DO  CASE 

k If   user  did  not  enter  a  expert  title, 

k — *  clear  the  screen  and  return  to  previous 

* program. 

CASE  ttitle  =  "  " 
CLEAR 

k If  service  number  does  not  exists, 

k add  a  expert  title. 

CASE  .NOT.  FOUND () 
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APPEND  BLANK 

REPLACE  expertitls  WITH  ttitle 

REPLACE  sn  WITH  sns 

* If  service  number  already  exists  in  the 

* EXPERT  file,  check  to  see  if  expert 

* title  already  exists  in  the  EXPERT  file. 

CASE  FOUND  0 

USE  expert  INDEX  expertitls 
ttitle  =  LOWER(ttitie) 
SEEK  ttitle 
DO  CASE 

CASE  FOUND  0 

@  20,10  SAY  ttitle  +  "already  exists" 

?  CHR(7) 

WAIT 

■k If  expert  title  not  already  taken, 

■k ]_gt  user  add  it. 

CASE  .NOT.  FOUND 0 
APPEND  BLANK 

REPLACE  expertitle  WITH  ttitle 
REPLACE  sn  WITH  sns 
ENDCASE 
ENDCASE 
ENDDO(While  user  does  not  enter  blank  for  expert  title) 
ENDCASE 
REINDEX 

CLEAR  ■   • 

ENDDO (While  user  does  not  enter  blank  for  service  number) 

■k Return  to  UPDATE  menu. 

RETURN 

d.  UPEDUCAT.PRG 

^■k-k-kkkkk*i(-ki^irirk-kkkkk-kirk-kk-kkk*i^-kkkiri^-k-k9rir-ki<:9;*-ki(-k*ifir-ki^ifif-k*ir9r*:9(-k-ki(-k* 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


UPEDUCAT.PRG 

KIM,   SAM  NAM 

31  NOV  86 

This  is  the  UPDATE  module  for  adding  education  results 

It  quries  the  user  for  task  selection  and  calls 

*  the  correct  module  to  service  that  request. 

*  When  control  is  returned  from  the  calling  module, 

*  the  user  is  asked  if  more  information  is  required 

*  If  yes,   then  the  process  is  repeated,  else,   the 

*  program  terminates. 
"-  ~  "  '  '         UPDATE 

MENUSCR,   UP_MEDI,   UP_M_ED2 


^   Called  by 

*  Modules  called 

*  Variables  used 

*  Global 


i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

kkkk'kkkki^irkkkkk-k-kkkkkk-kirkkkkkkkkkk'kkkkkk'kkkkkkkkk:kkkk-kkkk7<kkkkkkkkkkk-k 

''^  Set  up  looD  for  oresenting  menu. 

:*;  ^  T^c  :'c  ^^r  ric  5"?  T^c  ^Ic  :'c  7>c  A  7C  7*:  X  X  x  X  :<?  X  7*:  ^  3'c  A  A  X  3*:  9c  5*:  3t  ;t  7^:  X  >c  ?>c  :*:  7C  A  X  7k  :^ 

CLEAR 

DO  WHILE  .T. 

*  DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  DO  FOREVER 

*  The  DO  WHILE  will  be  terminated  by  an  EXIT  command 

*  Clear  the  screan  and  display  the  main  menu 
DO  MENUSCR 

(§2,11  SAY  "ADD   MILITARY   EDCATION   RESU; 
L  T  S" 

(§6,36  SAY  "SUBMENU" 

@  19,33  SAY  "INFORMATION" 

@  10,21  SAY  "A.  Add  military  education  results" 

d  11,21  SAY  "B.  Add  personal  education  results" 

(?  12,21  SAY  "C.  Change  date" 

(§  13,21  SAY  "X.  Exit'^ 

(?i  20,3  SAY  "DATE         TIME" 

(§  20,55  SAY  "UPDATED  BY" 

(a  21,5  SAY  today 
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Q   21,19  SAY  TIMEO 
*(§  21,52  SAY  gname 

(?  23,10  SAY  "  [  Enter  selection  (  A  -  C,  or  X  to  Exit  )  :  :  ]" 
DO  WHILE  .T. 
i=0 

DO  WHILE  i=0 
i=INKEY() 

(ci  21,19  SAY  TIMEO 
is  23,54  SAY  "" 
IF  UPPER(CHR(i))$"ABCX" 

EXIT 
END  IF 
i=0 
ENDDO 

(?  23,54  SAY  UPPER (CHR(i)) 
IF  .NOT.  CHR(i)$"Cc" 

EXIT 
END  IF 

SET  COLOR  TO  N/W 
@  19,33  SAY  "INFORMATION" 
(?  12,21  SAY  "C.  CHANGE  DATE" 
SET  COLOR  TO  W/N 
@  21,5  GET  today 
READ 

(a  21,5  SAY  today 
(B  19,33  SAY  "INFORMATION" 

•(?  12,21  SAY  "C.  Change  date"    ••  •    . 

(§  23,54  SAY  "  " 
ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 
RETURN 
CASE  CHR(i)$"Aa" 

DO  UP_M  EDI 
CASE  CHR(r)$"Bb" 
DO  UP_M_ED2 
ENDCASE 
ENDDO 

* when  done,  return  to  main  menu 

RETURN 

/.  UP_M_EDl.PRG 


*  Module  name 
"^   Author 
■^   Date 

*  Purpose 


UP_M_ED1.PRG 

PARK,   JAE  BOCK 

22  NOV  86 

This  is  the  UPEDCAT  module  for  adding  education  results 

*  '  It  sets  up  the  add  military  education  result,   accepts 

*  input  from  the  user  and  calls  the  required  modules. 

*  When  control  is  returned  from  the  called  module,   the 

*  user  is  asked  if  more  information  is  required  and  the 

*  the  process  is  repeated,   or  control  is  passed  back  to 

*  the  UPEDUCAT  module. 

UPEDUCAT 

SCREEN3 


*  Called  by 

*  Modules  called 
"^   Variables  used 

*  Global 


i  :  holds  the  value  of  the  user  input. 


*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  adding  new  officer  members. 

USE  m_educat  Index  m_educat 

name=  "x" 

DO  WHILE  name  ^   "  " 

CLEAR 

(§2,1  SAY  "Add  military  education  results" 

@  2,60  SAY  today 
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(?  2,70  SAY  TIKEO 

(?  3,0  SAY  ULINE 

"> 

'•? 

■k Get  proposed  course  name. 

name  =  SPACE (20) 

15  15,5  SAY  "Enter  course  name  (  or  press  RETURN; 

to  exit)"  GET  name 

READ 

•K Check  to  see  if  course  name  already  exists. 

name  =  LOWER (name) 
SEEK  name 
DO  CASE 

■k jf  user  did  not  enter  a  course  name, 

* clear  the  screen  and  return  to  UPEDUCAT  menu. 

CASE  name  =  "  " 
CLEAR 

* If  course  name  already  exists, 

■k notify  user  and  allow  another  try. 

CASE  FOUND  0 

(§  20,10  SAY  name  +  "already  exists" 

?  CHR(7) 

WAIT 

■k If  course  name  not  already  taken, 

* let  user  add  it. 

CASE  .NOT.  FOUND 0 
APPEND  BLANK 
REPLACE  cname  WITH  name 
SET  FORMAT  TO  screenS 
READ 

SET  FORMAT  TO 
ENDCASE 
ENDDO(While  user  does  not  enter  blank  for  service  number.) 
RE INDEX 

■k Return  tO  UPDATE  menu. 

RETURN 

2.  UP_M_ED2.PRG 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkiiifkk-k-k-k-kk-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-kk-k-k-k-kkk-k-k-k-k-k 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


UP_M_ED2.PRG 

PARK,   JAE  BOCK 

22  NOV  86 

This  is  the  UPEDUCAT  module  for  updating  military 

*  *  education  results  to  the  EDUCATMN  file. 

*  It  sets  up  the  add  military  education  results, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,    the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UPEDUCAT  module. 

*  Called  by      :UPEDUCAT 

*  Modules  called  :SCREEN2 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

■k-k-k-kk'k'k-kkkkkkkkkkkkkkkkkkkkkkkkkkk-k-kk-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-kk-kk-k-k-k-k-k-k-k-k-k-k 

*  Set  up  loop  for  adding  military  education  results. 

■k-k-kkkk-kkkkk-kkkkk7rkkkkyKkkkkkkkkkkkkkk-kkkkkkkkkkkkkkkkkkkkkkkkk-k-k-k:k*-k:k-kk 

USE  educatmn  INDEX  educatmn 
name  =  "x" 

DO  WHILE  sns  #  "  "  .OR.  name  #  "  " 

k Find  out  what  service  number  to  add. 

CLEAR 

(§2,1  SAY  "ADD  PERSONAL  EDUCATION  RESULTS" 
(§2,60  SAY  today 
@  2,70  SAY  TIMEt) 
(§3,0  SAY  ULINE 

134 


•> 

'•? 

*--_ Get  proposed  service  number  and  class  name. 

name  =  SPACS(20) 

sns  =  SFACE(S) 

@  15,5  SAY  "Add  for  what  service  number  ; 

"  GET  sns 
READ 

@  17,5  SAY  "Add  for  what  class  name" 
(a  18,7  SAY  "(  or  press  RETURN  to  exit)"  GET  name 
READ 

■k Try  to  find  that  service  number. 

sns  =  LOWER(sns) 
SEEK  sns 
DO  CASE 

■k jf  no  service  number  entered,  return  to  UPDATE  menu. 

CASE  sns  =  "  " 

CLEAR 

CASE  name  =  "  " 

CLEAR 

■k If  service  number  found,  try  to  find  that  class  name 

* and  add  using  screen2  format. 

CASE  .NOT.  FOUND 0 

USE  educatmn  INDEX  ccname 
snss  =  sns  +  name 
snss  =  lower(sns) 
SEEK  snss  ... 

IF  .NOT.  FOUND 0 
USE  educatmn 
APPEND  BLANK 
REPLACE  sn  WITH  sns 
REPLACE  cname  WITH  name 
SET  FORMAT  TO  screen2 
READ 

SET  FORMAT  TO 
ELSE 

(§5,0  CLEAR 

d  15,5  SAY  name  +  "   already  exists" 
?  CHR(7) 
WAIT 
END  IF 

* Otherwise, warn  user  and  allow  another  try 

CASE  FOUND  0 

(§17,5  SAY  "there  is  no  "  +  sns 
(§24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 
ENDDO( Continue  editing  until  user  requests  exit) 

* Return  tO  UPEDCAT  menu. 

RETURN 

e.  UPPROMOT.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


UPPROMOT.PRG 

PARK,   JAE  BOCK 

22  NOV  86 

This  is  the  UPDATE  module  for  adding  recent 

*  "  promotion  members  to  the  PROMOTE  database  file. 

*  It  sets  up  the  add  recent  promotion  members  menu, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,    the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UPDATE  module. 

*  Called  bv      : UPDATE 

*  Modules  called  :MENUSCR,   UPPROMOI,   UPPR0M02 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 
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*  Local   :  none 

*  Set  up  loop  for  adding  promotion  officers. 

CLEAR 

DO  WHILE  .T. 

*  DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  DO  FOREVER 

*  The  DO  WHILE  will  be  terminated  by  an  EXIT  command 

*  Clear  the  screan  and  display  the  main  menu 
DO  MENUSCR 

(§2,13  SAY  "ADD   RECENT    PROMOTION  RECORDS" 
(?  6,36  SAY  "SUBMENU" 
(B  19,33  SAY  "INFORMATION" 
@  10,21  SAY  "A.  Add  promotion  orders" 
@  11,21  SAY  "B.  Add  personal  promotion  records" 
(§  12,21  SAY  "C.  Change  date" 
(?  13,21  SAY  "X.  Exif^ 
(9  20,8  SAY  "DATE         TIME" 
(?  20,55  SAY  "UPDATED  BY" 
(?  21,5  SAY  today 
(B  21,19  SAY  TIMEO 
*(?  21,52  SAY  gname 

@  23,10  SAY  "  [  Enter  selection  (  A  -  C,  or  X  to  Exit  )  :  :  ]" 
DO  WHILE  .T. 
i=0 

DO  WHILE  i=0 
i=INKEY() 

(§  21,19  SAY  TIMEO 
(a  23,54  SAY  "" 
IF  UPPER(CHR(i))$"ABCX" 

EXIT 
END  IF 
i=0 
ENDDO 

(§  23,54  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"Cc" 

EXIT 
END  IF 

SET  COLOR  TO  N/W 
(§  19,33  SAY  "INFORMATION" 
(?  12,21  SAY  "C.  CHANGE  DATE" 
SET  COLOR  TO  W/N 
@  21,5  GET  today 
READ 

(a  21,5  SAY  today 
@  19,33  SAY  "INFORMATION" 
d  12,21  SAY  "C.  Change  date" 
@  23,54  SAY  "  " 
ENCDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 
RETURN 
CASE  CHR(i)$"Aa" 

DO  UPPROMOl 
CASE  CHR(i)$"Bb" 
DO  UPPR0M02 
ENDCASE 
ENDDO 

* when  done,  return  to  main  menu 

RETURN 

/.    UPPROMOl.PRG 


*  Module  name 

*  Author 
■^   Date 

*  Purpose 


UPPROMOl.PRG 
PARK,   JAE  BOCK 
22  NOV  86 
This  is  the 


e  UPPROMT  module  for  adding  promotion  orders 
*  to  the  RANK  file.  It  sets  up  the  add  promotion  oders, 
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*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  mere 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UPPRCMOT  module. 

*  Called  by      :  UPPROMOT 

*  Modules  called  :SCREEN4 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  adding  promotion  orders. 

USE  rank  Index  rank 

order  =  "x" 

DO  WHILE  order  #  "  " 

CLEAR 

(§2,1  SAY  "Add  recent  promotion  orders." 

(§2,60  SAY  today 

(§2,70  SAY  TIME() 

(§3,0  SAY  ULINE 

? 

* Get  proposed  promotion  order. 

order  =  SPACE (20) 

(§15,5  SAY  "Enter"  promotion  order  (  or  press  RETURN; 

to  exit)"  GET  order 

READ 

■k Check  to  see  if  promotion  order  already  exists. 

order  =  LOWER(order) 
SEEK  order 
DO  CASE 

■k If  user  did  not  enter  a  promotion  order, 

* clear  the  screen  and  return  to  UPPROMOT  menu. 

CASE  order  =  "  " 
CLEAR 

■k If   promotion  order  already  exists, 

■k notify  user  and  allow  another  try. 

CASE  FOUND () 

(§  20,10  SAY  order  +  "already  exists" 

?  CHR(7) 

WAIT 

k If   promotion  order  not  already  taken, 

* let  user  add  it. 

CASE  .NOT.  FOUND 0 
APPEND  BLANK 

REPLACE  p_order  WITH  order 
SET  FORMAT  TO  screen4 
READ 

SET  FORMAT  TO 
ENDCASE 
ENDDO (While  user  does  not  enter  blank  for  promotion  order) 
REINDEX 

k Return  tO  UPPROMOT  menu. 

RETURN 

2.    UPPROM02.PRG 

kk-kkkkkkkkkkkkkkkkkkkkkkkkkkkkk-kk-kkkkkk-kk-kk^-kk-k^-kk-k-kkkkkkkkkkk-kkkkkkkk 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


:UPPR0M02.PRG 

:PARK,   JAE  BOCK 

;22  NOV  86 

:This  is  the  UPPROMOT  module  for  adding  personal 

*  '         promotion  records  to  the  PROMOTE  file. 

*  It  sets  up  the  add  personal  promotion  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  •    from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 
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*  or  control  is  passed  back  to  the  UPPROMOT  module. 

*  Called  by  :  UPPROKOT 

*  Modules  called  :ncne 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local  :  none  -  • 

*  Set  up  loop  for  adding  personal  promotion  records. 

USE  main  INDEX  main 

sns  —  "x" 

DO  WHILE  sns  It  "  " 

CLEAR 

(§2,1  SAY  "Add  personal  promotion  records" 

(a  2,60  SAY  todav 

@  2,70  SAY  TIMET) 

(§  3,0  SAY  ULINE 

■k Get  proposed  service  number. 

sns  =  SPACE (8) 

@  15,5  SAY  "Enter  service  number  (  or  press  RETURN  to  exit)"  GET  sns 

READ 

* Check  to  see  if  service  number  already  exists. 

sns  =  LOWER(sns) 
SEEK  sns 
DO  CASE 

X If  user  did  not  enter  a  service  number, 

■k clear  the  screen  and  return  to  UPDATE  menu. 

CASE  sns  =  "  " 
CLEAR 

* If  service  number  does  not  exist, 

■k notify  user  and  allow  another  try. 

CASE  .NOT.  FOUND 0 

(§  20,10  SAY  sns  +  "does  not  exist" 

?  CHR(7) 

WAIT 

k If  service  number  already  exists, 

* let  user  add  it. 

CASE  FOUND  0 

USE  promote  INDEX  promote 

* Set  up  loop  for  adding  personal  promotion 

■k record. 

orders  =  "x" 
DO  WHILE  orders  tt  "  " 
CLEAR 

(§2,1  SAY  "Add  personal  promotion  records." 
(§2,60  SAY  today 
(§2,70  SAY  TIME() 
(§3,0  SAY  ULINE 
"? 

k Get  proposed  promotion  order. 

orders  =  SPACE (20) 

(§15,5  SAY  "Enter  promotion  order  (or  press  RETURN  to; 


exit)" 


(§  16,10  SAY  "(e.g  --->86-100  ARMY)"  GET  orders 

READ 

*--   Check  to  see  if  service  number  already  exists. 

SEEK  sns 

DO  CASE 

k If  user  did  not  enter  a  promotion  order, 

k clear  the  screen  and  return  to  previous 

* program. 

CASE  orders  =  "  " 
CLEAR 

k If  service  number  does  not  exists, 

* add  a  personal  promotion  record  to  PROMOTE 
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* file. 

CASE  .MOT.  FOUND 0 
APPEND  BLANK 

REPLACE  p_order  WITH  orders 
REPLACE  sn  WITH  sns 

* If  service  number  already  exists  in  the 

•k EDUCATMN  file,  check  to  see  if  course 

* name  already  exists  in  the  EDUCATMN  file. 

CASE  FOUND () 
FIND  sns 

COPY  TO  temp  WHILE  sn="sns" 
USE  temp 

INDEX  ON  p_order  TO  temp 
USE  temp  INDEX  temp 
orders  =  LOWER(orders) 
SEEK  orders 
DO  CASE 

CASE  FOUND  0 

(§  20,10  SAY  orders  +  "already  exists" 

?  CHR(7) 

WAIT 

* If  promotion  order  not  already  taken, 

■k let' user  add  it. 

CASE  .NOT.  FOUND 0 

USE  promote  INDEX  promote 
APPEND  BLANK 

REPLACE  p_order  WITH  orders  •  • 

REPLACE  sn  WITH  sns 
END CASE 
ENDCASE 
ENDDO(While  user  does  not  enter  blank  for  expert  title) 
ENDCASE 
RE INDEX 
CLEAR 
ENDDO(While  user  does  not  enter  blank  for  service  number.) 

* Return  to  UPDATE  menu. 

RETURN 

I.  UP_AW_PU.?RG 


*  Module  name 

*  Author 

*  Date 

*  Puroose 


UP_AW_PU . PRO 

KIM,   SAM  NAM 

22  NOV  56 

This  is  the  UPDATE  module  for  adding  awarded  and 

*  '  punished  members  to  the  AWARDPUN,   the  A_?_MN,   and 

*  the  A_P_?  database  files. 

*  It  set  up  the  add  award  and  punishment  records  menu, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UPDATE  module. 

*  Called  by      :  UPDATE 

*  Modules  called  :  MENUSCR,   UPAW_PU1 ,   UPAW_PU2,   UPAW_PU3 

*  Variables  used  : 

*  Global  :    i    :   holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  addinq  award  and  punishment  records. 

CLEAR 

DO  WHILE  .T. 

*  DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  DO  FOREVER 

*^   The  DO  WHILE  will  be  terminated  by  an  EXIT  command 

*  Clear  the  screan  and  display  the  main  menu 
DO  MENUSCR 

@  2,11  SAY  "ADD   AWARD   AND   PUNISHMENT   RE; 
CORDS" 
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(a  6,36  SAY  "SUBMENU" 

(?  19,33  SAY  "INFORMATION" 


(a  10,21  SAY 
@  11,21  SAY 
@  12,21  SAY 
(§  13,21  SAY 
(?  14,21  SAY 


A.  Add  award  and  punishment  points." 

B.  Add  personnel  order  of  award  and  punishment." 

C.  Add  personal  award  and  punishment  record." 

D.  Change  date" 
fi 


'X  Exit' 
(§20,8  SAY  "DATE         TIME" 
(§  20,55  SAY  "UPDATED  BY" 
(a  21,5  SAY  todav 
(§  21,19  SAY  TIMiO 
*(?  21,52  SAY  gname 

(?  23,10  SAY  "  [  Enter  selection  (  A  -  D,  or  X  to  Exit  )  :  :  ]" 
DO  WHILE  .T. 
i=0 

DO  WHILE  i=0 
i=INKEY() 

(?  21,19  SAY  TIMEO 
(?  23,54  SAY  "" 
IF  UPPER(CHR(i))$"ABCDX" 

EXIT 
ENDIF 
i=0 
ENDDO 

(§  23,54  SAY  UPPER(CHRfi)) 
IF  .NOT.  CHR(i)$"Dd" 

EXIT  ■  ■  ■   • 

ENDIF 

SET  COLOR  TO  N/W 
(§  19,33  SAY  "INFORMATION" 
(?  13,21  SAY  "D.  CHANGE  DATE" 
SET  COLOR  TO  W/N 
(§21,5   GET  today 
READ 

(§21,5  SAY  today 
(?  19,33  SAY  "INFORMATION" 
(B  13,21  SAY  "D,  Change  date" 
@  23,54  SAY  "  " 
ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 
RETURN 
CASE  CHR(i)$"Aa" 

DO  UPAW  PUl 
CASE  CHR(D$"Bb" 

DO  UPAW  PU2 
CASE  CHR(l)$"Cc" 
DO  UPAW_PU3 
ENDCASE 
ENDDO 

* when  done, return  to  main  menu 

RETURN 

/.    UPAW_PULPRG 


*  Module  name 
'^   Author 

*  Date 

*  Purpose 


UPAW_PU1 . PRG 

KIM,   SAM  NAM 

22  NOV  86 

This  is  the  UP_AW_PU  module  for  adding  award  and 


*  punishment  points  to  the  A_P_P  file. 

*  it  sets  up  the  add  award  and  punishment  points, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,    the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UP_AW_PU  module. 

*  Called  by      :  UP_AW_PU 

*  Modules  called  :  SCREENS 
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*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local  :  none 

************  A7>cA****:*::V:<t*  A  A  A^'cA^x**********^:^*****^:?^*****  A********* 

*  Set  up  loop  for  adding  award  and  cunishment  records. 

*****************.***************************9:**x****x***************** 

USE  a_p_p  Index  a_p_p 

kinds  =~'x" 

DO  WHILE  kinds  #  "  " 

CLEAR 

@  2,1  SAY  "Add  award  and  punishment  points." 

@  2,60  SAY  today 

(§2,70  SAY  TIME() 

(§  3,0  SAY  ULINE 

? 

* Get  proposed  award  and  punishment  name." 

kinds  =  SPACE (30) 

@  15,5  SAY  "Enter  award  and  punishment  name  (press  RETURN; 

to  exit)"  GET  kinds 

READ 

* Check  to  see  if  award  and  punishment  name  already  exists 

kinds  =  LOWER (kinds) 
SEEK  kinds 
DO  CASE 

* If  user  did  not  enter  a  award  and  punishment  name, 

* clear  the  screen  and  return  to  UP_AW_PU  menu. 

CASE  kinds  =  "  " 
CLEAR 

* Xf  award  and  punishment  name  already  exists, 

*--- notify  user  and  allow  another  try. 

CASE  FOUND  0 

(§  20,10  SAY  kinds  +  "already  exists" 

?  CHR(7) 

WAIT 

* If  award  and  punishment  name  not  already  taken, 

* Xet  user  add  it. 

CASE  .NOT.  FOUND 0 
APPEND  BLANK 
REPLACE  kind  WITH  kinds 
SET  FORMAT  TO  screenS 
READ 

SET  FORMAT  TO 
ENDCASE 
ENDDO(While  user  does  not  enter  blank  for  award  and  punishment; 
name . ) 
REINDEX 

* „ Return  tO  UP_AW_PU  menu. 

RETURN 

2.    UPAW_PU2.PRG 

********************************************************************* 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


UPAW_PU2 . PRG 
KIM,   SAM  NAM 
22  NOV  86 
^_ This  is  the  UP_AW  PU  module  for  adding  the 

*  personnel  order  oT  award  and  punishment  to  the  AWARDPUN 

*  file.  It  sets  up  the  add  personnel  order  of  award  and 

*  punishment,   accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UP_AW_PU  module. 

*  Called  by      :  UP_AW_PU 

*  Modules  called  : SCREENS 
'^   Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 
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*  Local  :  none 

*  Set  up  looD  for  adding  the  personnel  order. 

USE  awardpun  Index  awardpun 

award  =  "x" 

DO  WHILE  award  #  "  " 

CLEAR 

@  2,1  SAY  "Add  the  personnel  order  of  award  and  punishment." 

(a  2,60  SAY  today 

@  2,70  SAY  TIME() 

(§  3,0  SAY  ULINE 

p 

7 

* Get  proposed  oersonnel  order. 

award  =  SPACE (20) 

@  15,5  SAY  "Enter  personnel  order  (  or  press  RETURN; 

to  exit)"  GET  award 

READ 

* Check  to  see  if  personnel  order  already  exists. 

award  =  LOWER( award) 
SEEK  award 
DO  CASE 

* If  user  did  not  enter  a  personnel  order, 

* clear  the  screen  and  return  to  UP_AW_PU  menu. 

CASE  award  =  "  " 
CLEAR 

* If  personnel  order  already  exists, 

■k notify  user  and  allow  another  try. 

CASE  FOUND  0   * 

@  20,10  SAY  award  +  "already  exists" 

?  CHR(7) 

WAIT 

* If  personnel  order  not  already  taken, 

* let  user  add  it. 

CASE  .NOT.  FOUND 0 
APPEND  BLANK 

REPLACE  p_order  WITH  award 
SET  FORMAT  TO  screen6 
READ 

SET  FORMAT  TO 
ENDCASE 
ENDDO(While  user  does  not  enter  blank  for  personnel  order) 
REINDEX 

•k Return  to  UP_AW_PU  menu. 

RETURN 

3.    UPAW_PU3.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


UPAW_PU3 . PRO 

KIM,   SAM  NAM 

22  NOV  86 

This  is  the  UP_AW_PU  module  for  adding  personal 

*  '  award  and  punishment  records  to  the  A_P_MN  file. 

*  It  sets  up  the  add  personal  award  and  punishment 

*  records,   accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UP_AW_PU  module. 

*  Called  by      :  UP_AW_PU 

*  Modules  called  :  none 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  adding  military  education  results. 
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USE  main  INDEX  main 

sns  =  ''x" 

DO  \^1LE   sns  #  "  " 

CLEAR 

@  2,1  SAY  "Add  personal  award  and  punishment  records." 

@  2,60  SAY  today 

(a  2,70  SAY  TIMSt) 

(§  3,0  SAY  ULINE 

■k Get  proposed  service  number. 

sns  =  SPACE (8) 

(§15,5  SAY  "Enter  service  number  (  or  press  RETURN  to  exit)"  GET  sns 

READ 

* Check  to  see  if  service  number  already  exists. 

sns  =  LOWER (sns) 
SEEK  sns 
DO  CASE 

■k If   user  did  not  enter  a  service  number, 

■k clear  the  screen  and  return  to  UP_AW  _PU  menu. 

CASE  sns  =  "  " 
CLEAR 

■k If  service  number  does  not  exist, 

k notify  user  and  allow  another  try. 

CASE  .NOT.  FOUND 0 

(§  20,10  SAY  sns  +  "does  not  exist" 

?  CHR(7)         ■    ' 

WAIT 

k If   service  number  already  exists, 

k ]_et  user  add  it. 

CASE  FOUND  0 

USE  a_p_mn  INDEX  a_p_mn 

k Set  up  loop  for  adding  personal  award  and 

k punishment  records. 

order  =  "x" 
DO  WHILE  order  #  "  " 
CLEAR 

(§2,1  SAY  "Add  personal  award  and  punishment  records." 
(§2,60  SAY  today 
(§2,70  SAY  TIME() 
(§3,0  SAY  ULINE 

7 
■? 

k Qet  proposed  personnel  order. 

order  =  SPACE (20) 

(§15,5  SAY  "Enter  personnel  order  (or  press  RETURN  to; 


exit)' 


(§  16,10  SAY  "(e.g  --->86-100  ARMY)"  GET  order 

READ 

'^--   Check  to  see  if  service  number  already  exists. 

SEEK  sns 

DO  CASE 

* If  user  did  not  enter  a  personnel  order, 

k clear  the  screen  and  return  to  previous 

k program. 

CASE  order  =  "  " 
CLEAR 

k If  service  number  does  not  exists, 

k a(5d  a  personal  award  and  punishment 

k records  to  A_P_MN  file. 

CASE  .NOT.  FOUND 0 
APPEND  BLANK 

REPLACE  p_order  WITH  order 
REPLACE  sn  WITH  sns 

* If  service  number  already  exists  in  the 

* A_P_NN  file,  check  to  see  if  personnel 

k order  already  exists  in  the  A_P_I"IN  file. 

CASE  FOUND  0 
FIND  &sns 
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COPY  TO  temp  WHILE  sn="£<sns" 

USE  temp 

INDEX  ON  Dorder  TO  temp 

USE  temp  INDEX  temp 

order  =  LOWER(order) 

SEEK  order 

DO  CASE 

CASE  FOUND 0 

(3  20,10  SAY  order  +  "already  exists" 

?  CHR(7) 

WAIT 

■k xf  personnel  order  not  already  taken, 

* let  user  add  it. 

CASE  .NOT.  FOUND 0 

USE  a_p_mn  INDEX  a_p_mn 
APPEND  BLANK 

REPLACE  p_order  WITH  order 
REPLACE  sn  WITH  sns 
END CASE 
ENDCASE 
ENDDO(While  user  does  not  enter  blank  for  personnel; 
order. ) 

ENDCASE 
CLEAR 
ENDDO(While  user  does  not  enter  blank  for  service  number.) 

•k Return  to  UP_AW_PU  menu. 

RETURN  .  '  ■       • 

g.  UPEVAL.PRG 

k-k-k*kkkkkki<kkkkkkkkkifkkk*kkkki^*iri(-k-k-k*'kirkk-kki<:kkkkirkkkirkir7rirkkkkkkkkk 


*  Module  name 
^  Author 

*  Date 

*  Purpose 


UPEVAL.PRG 

KIM,   SAM  MAM 

22  NOV  36 

This  is  the  UPDATE  module  for  adding  personal 


*  performance  evaluation  records  to  the  P-EVAL  file. 

*  It  sets  up  the  add  performance  evaluation  records, 

*  accents  input  from  the  user  and  calls  the  required 

*  modules.  When  control  is  returned  from  the  called  module, 

*  the  user  is  asked  if  more  information  is  required  and 

*  the  process  is  repeated,   or  control  is  passed  back  to 

*  the  UPDATE  module. 

UPDATE 

SCREEN? 


*  Called  by 

*  Modules  called 

*  Variables  used 

*  Global 


i  :  holds  the  value  of  the  user  input. 


*  today:  holds  date 

*  Local   :  none 

*  Set  up  looD  for  adding  personal  performance  evaluation. 

USE  main  INDEX  main 

sns  ~  "x" 

DO  WHILE  sns  #  "  " 

CLEAR 

@  2,1  SAY  "Add  personal  performance  evaluation  records." 

(§2,60  SAY  today 

@  2,70  SAY  TIME() 

(§  3,0  SAY  ULINE 
■? 

7>c qqi   proposed  service  number. 

sns  =  SPACE (8) 

@  15,5  SAY  "Enter  service  number  (  or  press  RETURN  to  exit)"  GET  sns 

READ 

* Check  to  see  if  service  number  already  exists. 

sns  =  LOWER(sns) 
SEEK  sns 
DO  CASE 

* If  user  did  not  enter  a  service  number, 
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* clear  the  screen  and  return  to  UPDATE  menu. 

CASE  sns  =  "  " 
CLEAR 

* If  service  number  does  not  exist, 

* notify  user  and  allow  another  try. 

CASE  .NOT.  FOUND 0 

(?  20,10  SAY  sns  +  "does  not  exist." 

?  CHR(7) 

WAIT 

* If  service  number  already  exists, 

* let  user  add  it. 

CASE  FOUND  0 

USE  p_eval  INDEX  p_eval 

:* Set  up  loop  for  adding  personal 

* performance  evaluation  records. 

r'dd.ts  ~  "x" 
DO  WHILE  rdate  #  "  " 
CLEAR 

(§2,1  SAY  "Add  personal  performance  evaluation; 
records." 

@  2,60  SAY  today 
(§2,70  SAY  TIME() 
(B  3,0  SAY  ULINE 

*-- Get  proposed  rating  date. 

rdate  =  SPACE (8) 

(§15,5  SAY  "Enter  rating  date  (or  press  RETURN  to; 
exit) ." 

(?  16,10  SAY  "(e.g  --->MM/DD/YY) "  GET  rdate 

READ 

'^--  Check  to  see  if  service  number  already  exists. 

SEEK  sns 

DO  CASE 

■k If  user  did  not  enter  a  rating  date, 

* clear  the  screen  and  return  to  previous 

■k program. 

CASE  rdate  =  "  " 
CLEAR 

* If  service  number  does  not  exists, add 

■k a  personal  performance  evaaluation  record 

* to  P_EVAL  file. 

CASE  .NOT.  FOUND 0 
APPEND  BLANK 

REPLACE  ratingdate  WITH  rdate 
REPLACE  sn  WITH  sns 
SET  FORMAT  TO  screen? 
READ 
SET  FORMAT  TO 

■k If   service  number  already  exists  in  the 

k P_EVAL  file,  check  to  see  if  rating 

k date  already  exists  in  the  P_EVAL  rile. 

CASE  FOUND () 
FIND  &sns 

COPY  TO  temp  WHILE  sn="&sns" 
USE  temp 

INDEX  ON  ratingdate  TO  temp 
USE  temp  INDEX  temp 
rdate  =  LOWER( rdate) 
SEEK  rdate 
DO  CASE 

CASE  FOUND  0 

§  20,10  SAY  rdate  +  "   "  +  "already  exists. 

?  CHR(7) 

WAIT 

k If  rating  date  not  already  taken, 

k let  user  add  it. 

CASE  .NOT.  FOUND 0 

USE  p_eval  INDEX  p_eval 
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APPEND  BLANK 

REPLACE  ratingdate  WITH  rdate 
REPLACE  sn  WITH  sns 
SET  FORMAT  TO  screen? 
READ 

SET  FORIIAT  TO 
ENDCASE 
ENDCASE 
ENDDO (While  user  does  not  enter  blank  for  personnel; 
order. ) 

ENDCASE 
REINDEX 
CLEAR 
ENDDO (While  user  does  not  enter  blank  for  service  number) 
RETURN 

h.  UPCAREER.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


UPCAREER.PRG 

KIM,   SAM  NAM 

22  NOV  86 

This  is  the  UPDATE  module  for  adding  personal 

*  *         military  careers  to  the  CAREERS  file. 

*  It  sets  up  the  add  assignment  records, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  UPDATE  module. 

*  Called  by      :  UPDATE 

*  Modules  called  :  SCREENS 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  adding  military  career. 

USE  main  INDEX  main 

sns  =  "x" 

DO  WHILE  sns  #  "  " 

CLEAR 

@  2,1  SAY  "Add  assignment  records" 

@  2,60  SAY  today 

(§2,70  SAY  TIME() 

(a  3,0  SAY  ULINE 
? 

7 

* (3et  proposed  service  number. 

sns  =  SPACE (8) 

(§15,5  SAY  "Enter  service  number  (  or  press  RETURN  to  exit)"  GET  sns 

READ 

•k Check  to  see  if  service  number  already  exists. 

sns  =  LOWER(sns) 
SEEK  sns 
DO  CASE 

■k If  user  did  not  enter  a  service  number, 

■k clear  the  screen  and  return  to  UPDATE  menu. 

CASE  sns  =  "  " 

CLEAR 

* If  service  number  does  not  exist, 

* notify  user  and  allow  another  try. 

CASE  .NOT.  FOUND 0 

(§  20,10  SAY  sns  +  "does  not  exist." 

?  CHR(7) 

WAIT 

■k If   service  number  already  exists, 

k ]_gt  user  add  it. 

CASE  FOUND  0 
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USE  careers  INDEX  careers 

* Set  up  loop  for  adding  assignment  records. 

order  =  "x" 

DO  WHILE  order  #  "  " 

CLEAR 

@  2,1  SAY  "Add  assianment  records." 

(a  2,60  SAY  today 

@  2,70  SAY  TIMEO 

0  3,0  SAY  ULINE 

■k Qet  proposed  personnel  order. 

order  =  SPACE (20) 

@  15,5  SAY  "Enter  personnel  order  (or  press  RETURN  to; 
exit) . " 

@  16,10  SAY  "(e.g  --->85-100  army)"  GET  order 

READ 

'^--  Check  to  see  if  service  number  already  exists. 

SEEK  sns 

DO  CASE 

A If  user  did  not  enter  a  personnel  order, 

* clear  the  screen  and  return  to  previous 

■k program. 

CASE  order  =  "  " 
CLEAR 

■k jf  service  number  does  not  exists,  add 

* a  personal  asignment  record  to  CAREERS 

^ file. 

CASE  .MOT.  FOUND 0 
APPEND  BLANK 

REPLACE  p_order  WITH  order 
REPLACE  sn  WITH  sns 
SET  FORMAT  TO  screenS 
READ 
SET  FORMAT  TO 

■k If  service  number  already  exists  in  the 

k CAREERS  file,  check  to  see  if  personnel 

k order  already  exists  m  the  CAREERS  file. 

CASE  FOUND  0 
FIND  &sns 

COPY  TO  temp  WHILE  sn="&sns" 
USE  temp 

INDEX  ON  p_order  TO  temp 
USE  temp  INDEX  temp 
order  =  LOWER(order) 
SEEK  order 
DO  CASE 

CASE  FOUND  0 

(?  20,10  SAY  order  +  "   "  +  "already  exists." 

?  CHR(7) 

WAIT 

k If  personnel  order  not  already  taken, 

k let  user  add  it. 

CASE  .NOT.  FOUND  0 

USE  careers  INDEX  careers 
APPEND  BLANK 

REPLACE  p_order  WITH  order 
REPLACE  sn  WITH  sns 
SET  FORMAT  TO  screenS 
READ 

SET  FORMAT  TO 
ENDCASE 
ENDCASE 
ENDDO(While  user  does  not  enter  blank  for  personnel; 
order. ) 

ENDCASE 
CLEAR 
ENDDO(While  user  does  not  enter  blank  for  service  number) 
* Return  to  UPdDATE  MODULE. 
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RETUFN 

6.   EDIT.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


tEDIT.FRG  . 

;PARK,   JAE  BOCK 

;16  NOV  86 

:This  is  the  DRIVER  module  for  the  EDIT  function 

*  *  It  sets  up  the  main  edit  menu,   accepts  input 

*  from  the  user  and  calls  the  required  modules. 

*  When  control  is  returned  from  the  called  module, 

*  the  user  is  asked  if  more  information  is  required 

*  and  the  process  is  repeated  or  control  is  passed 

*  back  to  the  DRIVER  module. 

*  Called  by    :  DRIVER 

*  Modules  called  rMENUSCR,   EDEXPERT,   EDEDUCAT,   EDPROMOT,   EDAWARD, 

*  EDPUNISH,   EDEVAL,   EDCAREER 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today  :  holds  date 

*  Local  :  none 

*  Set  up  loop  for  presenting  menu. 

**:*c:>r^7^r*7>cA:*::i'f7*:Ax7*:Ax5':x7^xA*A:^3':7cxxxx7r7*:xAyc7^x7'fx 

CLEAR  ... 

DO  WHILE  .T. 
CLEAR 

DO  MENUS CR 

(§2,20   SAY   "EDIT        PERSONNEL        RECORD" 
(§6,34   SAY    "SUBMENU" 
(§   19,33    SAY    "INFORMATION" 

(§9,5  SAY  "A.  Edit  personal  personnel  record." 
(§  10,5  SAY  "B.  Edit  expert  record." 
(§11,5  SAY  "C.  Edit  military  education" 
(§12,8  SAY  "  result." 

(§13,5  SAY  "D.  Edit  promotion  record." 
(§14,5  SAY  "E.  Edit  award  and  punishment  record." 
(§  9,42  SAY  "F.  Edit  performance  evaluation" 
(§  10,45  SAY  "  record." 

(§  11,42  SAY  "G.  Edit  assignment  record." 
(§  13,42  SAY  "I.  Change  date" 
(§  14,42  SAY  "X.  Return  to  main  menu" 
(§20,8  SAY  "DATE         TIME" 
(§  20,55  SAY  "UPDATED  BY" 
(§21,5  SAY  today 
(§  21,19  SAY  TIMEO 
^(§  21,52  SAY  gname 

(§  23,10  SAY  "[Enter  selection  (A  -G,  I,  or  X  to  return  to  main" 
(§  23,57  SAY  "  menu)  :  :  ]" 
DO  WHILE  .T. 
i=0 

DO  WHILE  i=0 
i=INKEY() 

(§  21,19  SAY  TIMEO 
(§  23,65  SAY  "" 
IF  UPPER(CHR(i))$"ABCDEFGIX" 

EXIT 
END  IF 
i=0 
ENDDO 

(§  23,65  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"Ii" 

EXIT 
ENDIF 

SET  COLOR  TO  N/W 
(§  19,33  SAY  "INFORMATION" 
@  13,42  SAY  "I.  CHANGE  DATE" 
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SET  COLOR  TO  W/N 
(§21,5  GET  today 
READ 

(a  21,5  SAY  today 
(§  19,33  SAY  "INFORMATION" 
§  13,42  SAY  "I.  Change  date" 
@  23,65  SAY  "  " 
ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 
RETURN 
CASE  CHR(i)$"Aa" 

DO  EDNAIN 
CASE  CHR(i)$"Bb" 

DO  EDEXPERT 
CASE  CHR(i)$"Cc" 

DO  EDEDUCAT 
CASE  CHR(i)$"Dd" 

DO  EDPROMOT 
CASE  CHR(i)$"Ee" 

DO  ED_AW  PU 
CASE  CHR(ir$"Ff" 

DO  EDEVAL 
CASE  CHR(i)$"Gg" 
DO  EDCAREER 
END CASE 
ENDDO 

X when  done,   return  to  main  menu. 

RETURN 

a.  EDMAIN.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


;  EDMAIN.PRG 

;PARK,       JAE   BOCK 

;22  NOV   86 

;This  is  the  EDIT  module  for  editing  personnel  record. 

*  *  It  sets  up  the  edit  prsonal  personnel  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDIT  module. 
■  -  ■■  •  •         EDIT 

iSCREENll 


*  Called  by 

*  Modules  called 

*  Variables  used 

*  Global 


i  :  holds  the  value  of  the  user  input. 


*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  editing  personnel  record. 

USE  main  Index  main 

sns  ~  "x" 

DO  WHILE  sns  #  "  " 

* Find  out  what  service  number  to  edit. 

CLEAR 

©  2,1  SAY  "EDIT  PERSONNEL  RECORD" 

@  2,60  SAY  today 

(a  2,70  SAY  TIME() 

(§3,0  SAY  ULINE 

* Get  proposed  service  number. 

sns  =  SPACE (8) 

(§15,5  SAY  "Edit  for  what  service  number  (  or  press  RETURN; 

to  exit)"  GET  sns 

READ 

■k jj-y  to  find  that  service  number. 
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sns  =  LOWER(sns) 
SSEK  sns 
DO  CASE 

•k If  no  service  number  entered,  return  to  EDIT  menu. 

CASE  sns  =  "  " 
CLEAR 

*^ If  service  number  found,  edit  using  SCREENl  format. 

CASE  FOUND  0 

SET  FORMAT  TO  screenll 

READ 

SET  FORMAT  TO 

■k Otherwise,   warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND () 

(§17,5  SAY  "There  is  no  "  +  sns  +  "number." 
(?  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 
ENDDO( Continue  editing  until  user  requests  exit) 

7c Return  tO  EDIT  menu. 

RETURN 

b.  EDEXPERT.PRG 

:k-kkkkkkkkkkkkki<kkyrkkkkkkkkkkk-k'kiKi(i^-kirkkkkkkkkkkkkkkki^if^**-kifii**i<****kkkk 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


;EDEXPERT.PRG 

iKIM,   SAM  NAM 

;22  NOV  86 

:This  is  the  EDIT  module  for  editing  an  expert  record. 

*  '  It  sets  up  the  edit  expert  record,   accepts  input  from 

*  the  user  and  calls  the   required  modules. 

*  When  control  is  returned  from  the  called  module, 

*  the  user  is  asked  if  more  information  is  required  and 

*  the  process  is  repeated,   or  control  is  passed  back 

*  to  the  EDIT  module. 

EDIT 
SCREEN9 


*  Called  by 

*  Modules  called 

*  Variables  used 

*  Global 


i  :  holds  the  value  of  the  user  input. 
'^  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  editing  an  expert  record. 

USE  expert  INDEX  expert 
title  =  "X" 
sns  —  "x" 

DO  WHILE  sns  #  "  "  .AND.  title  #  "  " 
* Find  out  what  service  number  to  edit. 

CLEAR 

(§2,1  SAY  "EDIT  EXPERT  RECORD" 

@  2,60  SAY  today 

(§  2,70  SAY  TIME() 

@  3,0  SAY  ULINE 

7 
'■? 

* Get  proposed  service  number. 

title  =  SPACE(20) 

sns  =  SPACE(8) 

(§15,5  SAY  "Edit  for  what  service  number  (  or  press  RETURN; 

to  exit)"  GET  sns 

READ 

(§15,5  SAY  "Edit  for  what  expert  title   (  or  press  RETURN; 

to  exit)"  GET  title 

READ 

* Try  to  find  that  service  number. 

sns  =  LOWER(sns) 
SEEK  sns 
DO  CASE 

* If  no  service  number  entered,  return  to  EDIT  menu. 

CASE  sns  =  "  " 
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CLEAR 

CASE  title  =  "  " 

CLEAR 

* If  service  number  found,  edit  using  screen9  forxiat. 

CASE  FOLT\^D() 

USE  expert  INDEX  expertitle 
sns  =  sns  +  title 
sns  =  lower(sns) 
SEEK  sns 
IF  FOUND 0 

SET  FORMAT  TO  screen9 
READ 

SET  FORMAT  TO 
ELSE 

(§5,0  CLEAR 

@  15,5  SAY  title  +  "   Not  found" 
?  CHR(7) 
WAIT 
END  IF 

■k Otherwise , warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND 0 

(§17,5  SAY  "There  is  no  "  +  sns  +  "  number." 
I  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 
ENDDO( Continue  editing  until  user  requests  exit.) 

■k __  Return  tO  EDIT  menu.    ■  . 

RETURN 

c.  EDEDUCAT.PRG 

k*ki^kkkkkkkki<:kkkkki<:kkkiririK*kkkki<:kirkkkkkk-kkki<:irk-kk-kkkkkkkkk*k-kkkkkkkirk-k-k-k 


*  Module  name 
'^   Author 

*  Date 

*  Purpose 


EDEDUCAT.PRG 

PARK,   JAE  BOCK 

22  NOV  36 

This  is  the  EDIT  module  for  editing  military  education 

*  "  record.  It  sets  up  the  edit  military  education  result, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDIT  module. 

*  Called  by      :  EDIT 

*  Modules  called  :  none 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today-,  holds  date 

*  Local   :  none 

*  Set  up  loop  for  editing  education  result. 

CLEAR 

DO  WHILE  .T. 

^   DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  Do  forever 

"^   The  DO  WHILE  will  be  terminated  by  an  EXIT  command. 

'^  Clear  the  screan  and  display  the  mam  menu. 

DO  MENUSCR 

(§2,12    SAY    "EDIT      MILITARY        EDUCATION" 

(§6,36    SAY    "SUBMENU" 

(§  19,33  SAY  "INFORMATION" 

(§  10,21  SAY  "A, Edit  military  education  result." 

(§  11,21  SAY  "B.Edit  personal  education  result." 

(?  12,21  SAY  "C.  Change  date" 

@  13,21  SAY  "X.  Exit" 

§  20,8  SAY  "DATE         TIME" 

(§  20,55  SAY  "UPDATED  BY" 

@  21,5  SAY  todav 

@  21,19  SAY  TIMSO 

*(?  21,52  SAY  gname 

@  23,10  SAY  "  [  Enter  selection  (  A  -  C,  or  X  to  Exit  )  :  :  ]" 
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DO  WHILE  .T. 
i=G 

DO  WHILE  i=0 
i=INKEY() 

(a  21,19  SAY  TIMEO 
@  23  54  SAY  "" 
IF  UPFER(CHR(i))$"ABCX" 

EXIT 
ENDIF 
i=0 
ENDDO 

(§  23,54  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"Cc" 

EXIT 
ENDIF 

SET  COLOR  TO  N/W 
(?  19,33  SAY  "INFORMATION" 
@  12,21  SAY  "C.  CHANGE  DATE" 
SET  COLOR  TO  W/N 
(§21,5   GET  today 
READ 

(§21,5  SAY  todav 
(?  19,33  SAY  "INFORMATION" 
@  12,21  SAY  "C.  Change  date" 
(?  23,54  SAY  "  " 
-  ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 
RETURN 
CASE  CHR(i)$"Aa" 

DO  ED_M  EDI 
CASE  CHR(r^$"Bb" 
DO  ED_M_ED2 
ENDCASE 
ENDDO 

■k Return  to  EDIT  menu. 

RETURN 

/.   EDjVI^EDI.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


ED_M_ED1.PRG 

KIM,   SAM  NAM 

22  NOV  36 

This  is  the  EDEDCAT  module  for  editing  military 

*  '  education  results.  It  sets  up  the  edit  military  education 

*  result,   accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

^  information  is  required  and  the  process  is  repeated, 

^  or  control  is  passed  back  to  the  EDEDUCAT  module. 

*  Called  by      :  EDEDUCAT 

*  Modules  called  :SCREEN31 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 
'^         Local   :  none 

*  Set  UD  loop  for  editing  personnel  record. 

^c  ^  :^  ^  X  ;*:  :^  7^:  jlr  r'c  :*c  T^c  7*:  TT  tIc  TT  9c  X  7c :«:  X  x  X  X  t'c  5^^  tIc  ^'c  x  A  >:  X  X  Tt  A  ^  3<r  A  X 

USE  m_educat  Index  m_educat 

DO  WHILE  class  #  "  " 

■k Find  out  what  class  name  to  edit. 

CLEAR 

@  2,1  SAY  "EDIT  MILITARY  EDUCATION  RESULTS" 

(§2,60  SAY  today 

(§  2,70  SAY  TIME() 

@  3,0  SAY  ULINE 
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* Get  proposed  class  name. 

class  =  SPACE* 20) 

!?  15,5  SAY  "Edit  for  what  class  name  (  or  press  RETURN; 

to  exit)"  GET  class 

READ 

* Try  to  find  that  class  name. 

class  =  LOWER(class) 
SEEK  class 
DO  CASE 

•k If  no  class  name  entered,  return  to  EDCAT  menu. 

CASE  class  =  "  " 
CLEAR 

:k If  class  name  found,  edit  using  SCREENl  format. 

CASE  FOUND  0 

SET  FORMAT  TO  screen31 

READ 

SET  FORMAT  TO 

:«r Otherwise, warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND () 

{?  17,5  SAY  "There  is  no  "  +  class 
d  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 
ENDDO( Continue  editing  until  user  requests  exit.) 

* Return  tO  EDCAT  menu. 

RETURN 

2.  ED_M_ED2.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


;ED_M_ED2.PRG 

:KIM,   SAM  NAM 

:22  NOV  86 

;This  is  the  EDEDCAT  module  for  editing  personal 

*  '  education  results. 

*  It  sets  UD  the  edit  personal  education  result, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDEDCAT  module. 

*  Called  by      :  EDEDCAT 

*  Modules  called  :  SCREEN21 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  editing  oersonal  education  result. 

USE  educatmn  INDEX  educatmn 
name  =  "x" 
sns  —  " x" 

DO  WHILE  sns  #  "  "  .OR.  name  #  "  " 
* Find  out  what  service  number  to  edit. 

CLEAR 

@  2,1  SAY  "EDIT  PERSONAL  EDUCATION  RESULTS" 

@  2,60  SAY  today 

(§2,70  SAY  TIMEt) 

(§3,0  SAY  ULINE 

? 

* Get  proposed  service  number  and  class  name. 

name  =  SPACE (20) 

sns  =  SPACE (3) 

(§15,5  SAY  "Edit  for  what  service  number  ; 

"  GET  sns 
READ 
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(?  17,5  SAY  "Edit  for  what  class  name" 

@  ie,7  SAY  "(  or  press  RETURN  to  exit)"  GET  name 

READ 

^ Tfy  to  find  that  service  number.  "  " 

sns  =  LOWER (sns) 
SEEK  sns 
DO  CASE 

* If  no  service  number  entered,  return  to  EDIT  menu. 

CASE  sns  =  "  " 

CLEAR 

CASE  name  =  "  " 

CLEAR 

* If  service  number  found,  try  to  find  that  class  name 

■k an(^  edit  using  screen21  format. 

CASE  FOUND  0 

USE  educatmn  INDEX  ccname 
sns  =  sns  +  name 
sns  =  lower (sns) 
SEEK  sns 
IF  FOUND  0 

SET  FORMAT  TO  screen21 
READ 

SET  FORMAT  TO 
ELSE 

(?  5,0  CLEAR 

@  15,5  SAY  name  +  "   Not  found" 
?  CHR(7)  ■  - 

WAIT 
END  IF 

* Otherwise , warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND 0 

@  17,5  SAY  "There  is  no  "  +  sns 
(§  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 
ENDDO( Continue  editing  until  user  requests  exit.) 

■k Return  to  EDEDCAT  menu. 

RETURN 

d.  EDPROMOT.PRG 

*kkkkkkkkkkkkkkkkkkkkkkkkkkk^i(^*i(i(^*:i<i^-k**:i<-k*:i^***i^*******-k***-k-k-k-k**-k-k* 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


:  EDPROMOT.PRG 

:KIM,   SAM  NAM 

;22  NOV  86 

:This  is  the  EDIT  module  for  editing  promotion 

*  '  records.  It  sets  up  the  edit  promotion  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDIT  module. 

*  Called  by      :  EDIT 

*  Modules  called  :  none 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  editing  education  result. 

*:kkkkkkkkkkkkkkkJ^kkkk%kkkkkkkkkkk^kkkkkkkkkkkkk*kirkkkkkkkkkkkkkk-k-k-k-k-k-k 

CLEAR 

DO  WHILE  .T. 

*  DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  Do  forever. 

*  The  DO  WHILE  will  be  terminated  by  an  EXIT  command. 

*  Clear  the  screan  and  display  the  main  menu. 
DO  HENUSCR 
(?  2,12  SAY  "E  D  I  T   P  R  M  0  T  I  0  N   RECORD" 


@  6,36  SAY  "SUBMENU" 

(§  19,33  SAY  "INFORMATION" 
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@  10,21  SAY  "A. Edit  promotion  record." 
@  11,21  SAY  "B.Edit  personal  promotion  record." 
@  12,21  SAY  "C.Chanqe  date" 
(a  13,21  SAY  "X.Exit" 
(§20,8  SAY  "DATE         TIME" 
(§  20,55  SAY  "UPDATED  BY" 
.  ©  21,5  SAY  today 
(?  21,19  SAY  TIMEO 
*(§  21,52  SAY  gname 

@  23,10  SAY  "  [  Enter  selection  (  A  -  C,  or  X  to  Exit  )  :  :  ]" 
DO  WHILE  .T. 
i=0 

DO  WHILE  1=0 
i=INKEY() 

(a  21,19  SAY  TIMEO 
(?  23,54  SAY  "" 
IF  UPPER(CHR(i))$"ABCX" 

EXIT 
END  IF 
i=0 
ENDDO 

(?  23,54  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"Cc" 

EXIT 
ENDIF 

SET  COLOR  TO  N/W 
^   19,33  SAY -"INFORMATION" 
(?  12,21  SAY  "C.  CHANGE  DATE" 
SET  COLOR  TO  W/N 
(§21,5  GET  today 
READ 

@  21,5  SAY  today 
(§  19,33  SAY  "INFORMATION" 
(§  12,21  SAY  "C.  Change  date" 
(B  23,54  SAY  "  " 
ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 
RETURN 
CASE  CHR(i)$"Aa" 

DO  EDPROMOl 
CASE  CHR(i)$"Bb" 
DO  SDPR0M02 
ENDCASE 
ENDDO 

* Return  to  EDIT  menu. 

RETURN 

/.   EDPROMOl.PRG 


*  Author 

*  Date 

*  Purpose 


*  Module  name   :EDPR0M01 .PRG 
KIM,   SAM  NAM 
22  NOV  86 

This  is  the  EDPROMOT  module  for  editing  promotion 
record.  It  sets  up  the  edit  promotion  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDPROMOT  module. 


EDPROMOT 
SCREEN41 


*  Called  by 

*  Modules  called 

*  Variables  used 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  editing  PROMOTION  record. 
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USE  rank  Index  rank 

order  =  "x'' 

DO  WHILE  order  #  "  " 

* Find  out  what  promotion  order  to  edit. 

CLEAR 

@  2,1  SAY  "EDIT  PROMOTION  RECORDS" 

@  2,60  SAY  today 

@  2,70  SAY  TIME() 

@  3,0  SAY  ULINE 

? 

* Get  proposed  promotion  order. 

order  =  SPACE (20) 

@  15,5  SAY  "Eait  for  what  promotion  order  (  or  press  RETURN; 

to  axit)"  GET  order 

READ 

* Try  to  find  that  promotion  order. 

order  =  LOWER(order) 
SEEK  order 
DO  CASE 

A If   no  promotion  order  entered,  return  to  EDPROMOT  menu. 

CASE  order  =  "  T" 
CLEAR 

■k If  promotion  order  found,  edit  using  SCREEN4  format. 

CASE  FOUND () 

.  SET  FORMAT  TO  screen41       ...  ■     . 

READ 
SET  FORMAT  TO 

* Otherwise, warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND 0 
CLEAR 

(§17,5  SAY  "There  is  no  "  +  order 
d  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCA3E 
ENDDO(Continue  editing  until  user  requests  exit.) 

■k Return  to  EDPROMOT  menu. 

RETURInI 

2.   EDPR0M02.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


:EDPR0M02.PRG 

;KIM,   SAM  NAM 

;22  NOV  86 

;This  is  the  EDPROMOT  module  for  editing  personal 

*  '         promotion  record. It  sets  up  the  edit  personal  promotion 

*  record,   accepts  input  from  the  user  and  calls  the 

*  required  modules,  when  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDPROMOT  module. 

*  Called  by      :  EDPROMOT 

*  Modules  called 

*  Variables  used  . 

*  Global  :  i  :  holds  the  value  of  the  user  input, 

*  today:  holds  date. 

*  Local      :    none 

kirirkki<:kki<:kkkkkkkkkkkirirkkikkkkkkkkkkkkkkkkiri^i(-kiK:k*i^irk-k'^if*ivir-^ 

*  Set  up  loop  for  editing  personal  promotion  record. 

USE  promote  INDEX  promote 
order  =  "x" 
sns  =  "x" 

DO  WHILE  sns  #  "  "  .OR.  order  #  "  " 
k Find  out  what  service  number  to  edit. 

CLEAR 

@  2,1  SAY  "EDIT  PERSONAL  PROMOTION  RECORDS" 

(§2,60  SAY  today 
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(?  2,70   SAY  TIMEO 
@  3,0   SAY  ULINE 

? 

* Get  proposed  service  number  and  promotion  order. 

order  =  SPACE{20) 

sns  =  SPACE (8) 

(§15,5  SAY  "Edit  for  what  service  number  .  ; 

"  GET  sns 
READ 

@  17,5  SAY  "Edit  for  what  promotion  order" 
(§18,7  SAY  "  (  or  press  RETURN  to  exit)"  GET  order 
READ 

* Try  to  find  that  service  number. 

sns  =  LOWER (sns) 
SEEK  sns 
DO  CASE 

* If  no  service  number  entered,  return  to  EDPROMOT  menu. 

CASE  sns  =  "  " 

CLEAR 

CASE  order  =  "  " 

CLEAR 

•k If  service  number  found,  try  to  find  that  promotion 

* order  and  edit  it. 

CASE  FOUND () 

USE  promote  INDEX  p_order 
sns  =  sns  +  order 
sns  =  lower(sns) 
SEEK  sns 
IF  FOUND 0 

SET  FORMAT  TO  screenlO 
READ 

SET  FORMAT  TO 
ELSE 

@  5,0  CLEAR 

(§15,5  SAY  order  +  "   Not  found" 
?  CHR(7) 
WAIT 
END  IF 

■k Otherwise, warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND () 
CLEAR 

@  17,5  SAY  "There  is  no  "  +  sns 
@  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 
ENDDO( Continue  editing  until  user  requests  exit.) 

* Return  to  EDPROMOT  menu. 

RETURN 

e.  ED_AVV_PU.PRG 

*i<:kkkk*kkkkkkk*kkkkk:kkirkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk-k-k-k-k-k-k 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


ED_AW_PU . PRG 

KIM,   SAM  NAM 

22  NOV  86 

This  is  the  EDIT  module  for  editing  award  and  punishment 

*  '  record.  It  sets  up  the  edit  award  and  punishment  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDIT  module. 

*  Called  by      :  EDIT 

*  Modules  called 

*  Variables  used 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 
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*         Set  up  loop  for  editing  award  and  punishment  record. 

CLEAR 

DO  WHILE  .T. 

*  DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  DO  FOREVER 

*  The  DO  WHILE  will  be  terminated  by  an  EXIT  command 

*  Clear  the  screan  and  display  the  main  menu 
DO  MENUSCR 

@  2,12  SAY  "EDIT  AWARD  PUNISHMENT  RECORD  " 
@  6,36  SAY  "SUBMENU" 


(§  19,33  SAY 


(a  10,21  SAY 

(5  11,21  SAY 

(§  12,21  SAY 

(?  13,21  SAY 

(?  14,21  SAY 


INFORMATION 


'A. Edit  award  and  punishment  points." 
'B.Edit  award  and  punishment  record." 
'C.Edit  personal  award  and  punishment  record." 
'D. Change  date." 
'X.Exit" 
(§20,3  SAY  "DATE         TIME" 
(§  20,55  SAY  "UPDATED  BY" 
(§21,5  SAY  today 
(?  21,19  SAY  TIMEO 
*(^   21,52  SAY  gname 

(§  23,10  SAY  "  [  Enter  selection  (  A  -  D,  or  X  to  Exit  )  :  :  ]" 
DO  WHILE  .T. 
i=0 

DO  WHILE  i=0 
i=INKEY() 

(?  21,19  SAY  TIMEO  '   ' 

(§  23,54  SAY  "" 
IF  UPPER (CHR(i))$"ABCDX" 

EXIT 
ENDIF 
i=0 
ENDDO 

(§  23,54  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"Dd" 

EXIT 
ENDIF 

SET  COLOR  TO  N/W 
(§  19,33  SAY  "INFORMATION" 
(§  13,21  SAY  "D.  CHANGE  DATE" 
SET  COLOR  TO  W/N 
(§21,5  GET  today 
READ 

(§21,5  SAY  today 
(§  19,33  SAY  "INFORMATION" 
@  13,21  SAY  "D.  Change  date" 
(§  23,54  SAY  "  " 
ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 
RETURN 
CASE  CHR(i)$"Aa" 

DO  EDAW  PUl 
CASE  CHR(r)$"Bb" 

DO  EDAW  PU2 
CASE  CHR(i)$"Cc" 
DO  EDAW_PU3 
ENDCASE 
ENDDO 

•k Return  tO  EDIT  menu. 

RETURN 

/.   EDAW^PUl.PRG 


*  Module  name 
'^  Author 

*  Date 

*  Purpose 


EDAW_PU1.PRG 

KIM,   SAM  NAM 

22  NOV  86 

This  is  the  ED_AW_PU  module  for  editing  award  and 
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*  punishment  ponits.  It  sets  up  the  edit  award  and 

*  punishment  points,   accepts  input  from  the  user  and 
"*"  calls  quired  modules.  V/hen  control  is  returned 

from  the  called  module,   the  user  is  asked  if 


more 


*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  ED_AW_PU  module. 

*  Called  bv      :  ED_AW_PU 

*  Modules  called  :  SCREEN51 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  editing  award  and  punishment  point. 

USE  a_p_p  Index  a_p_p 

award  =~^'x" 

DO  WHILE  award  #  "  " 

■k Find  out  what  award  and  punishment  point  to  edit. 

CLEAR 

(§2,1  SAY  "EDIT  AWARD  AND  PUNISHMENT  POINTS" 

@  2,60  SAY  today 

(§2,70  SAY  TIME() 

(?  3,0  SAY  ULINE 

? 

? 

* i Get  proposed  type  of  award  and  punishment. 

award  =  SPACE (30) 

(§15,5  SAY  "Eait  for  what  kind  of  award  and  punishment" 

(§16,7  SAY  "(  or  press  RETURN  to  exit)"  GET  award 

READ 

■k Try  to  find  that  kind  of  award  and  punishment. 

award  =  LOWER (award) 
SEEK  award 
DO  CASE 

* If  no  kind  of  awardand  punishment  entered, 

*- return  to  ED_AW_PU  menu. 

CASE  award  =  "  " 
CLEAR 

* If  kind  of  award  and  punishment  found, 

■k edit  using  SCREENS  format. 

.  CASE  FOUND  0 

SET  FORMAT  TO  screenSl 

READ 

SET  FORMAT  TO 

Tic Otherwise , warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND () 
CLEAR 

(?  17,5  SAY  "There  is  no  "  +  award 
d  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 
ENDDO( Continue  editing  until  user  requests  exit.) 

■k Return  to  ED_AW_PU  menu. 

RETURN 

2.   EDAW_PU2.PRG 

■k-kkkk-kkkkkkkkkk-kkkkkkk-kkkkk-kkkk-kkkkk-kkkkkkkkkkkkk-kkk-k-k-k-k-k-k-kkk-kk-kkkkk-k 


*  Module  name 

*  Author 

*  Date 
Purpose 


k 


EDAW_PU2.PRG 

KIM,   SAM  NAM 

22  NOV  86 

This  is  the  ED_AW_PU  module  for  editing  award  and 

*  punishment  records. 

*  It  sets  up  the  edit  award  and  punishment  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  ED_AW__PU  module. 
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*  Called  by  :  ED  AW_PU 

*  Modules  called  :SCREEN61 
=^  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local  :  none 

*  Set  up  looD  for  editing  award  and  punishment  point. 

USE  awardpun  Index  awardpun 

award  =  "x" 

DO  WHILE  award  #  "  " 

* Find  out  what  award  and  punishment  record  to  edit. 

CLEAR 

(§2,1    SAY    "EDIT   AWARD   AND   PUNISffilENT   RECORDS" 

(§2,60  SAY  today 

@  2,70  SAY  TIMEl) 

(§3,0  SAY  ULINE 

? 

'■> 

* Get  proposed  PRSONNEL  ORDER. 

award  =  SPACE (20) 

(§15,5  SAY  "Edit  for  what  oersonnel  order" 

(§16,7  SAY  "(  or  press  RETtjRN  to  exit)"  GET  award 

READ 

■k -pi-y  to  find  that  personnel  order. 

award  =  LOWER(award) 
SEEK  award 
DO  CASE 

X If  no  personnel  order  entered, return  to  ED_AW_PU  menu. 

CASE  award  =  "  ^' 
CLEAR 

■k If  personnel  order  found,  edit  using  SCREEN61  format. 

CASE  FOUND  0 

SET  FORMAT  TO  screen61 

READ 

SET  FORMAT  TO 

■k Otherwise,   warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND () 
CLEAR 

(§17,5  SAY  "There  is  no   "  +  award 
(§  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 
ENDDO( Continue  editing  until  user  requests  exit.) 

k Return  tO  ED_AW_PU  menu. 

RETURN 

3.   EDAW_PU3.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


EDAW_PU3.PRG 

KIM,   SAM  NAM 

22  NOV  36 

This  is  the  ED_AW_PU  module  for  editing  personal 

*  *  award  and  punishment  records. 

*  It  sets  up  the  edit  personal  award  and  punishment  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  ED_AW_PU  module. 
"  ~  "'  '  '  ED_AW_PU 

none 


*  Called  by 

*  Modules  called 

*  Variables  used 

*  Global 


i  :  holds  the  value  of  the  user  input, 


*  today:  holds  date 

*  Local   :  none* 

*  Set  up  loop  for  editing  personal  award  and  punishment  record. 
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USE  a_p_mn  INDEX  a_p_ir.n 
order  =  "x" 
sns  =  "x" 

DO  V1H1LE   sns  #  "  "  .OR.  order  #  "  " 
X Find  out  what  service  number  to  edit. 

(S  2,"l  SAY  "EDIT  PERSONAL  AWARD  AND  PUNISHMENT  RECORDS." 

@  2,60  SAY  today 

@  2,70  SAY  TIME() 

(a  3,0  SAY  ULINE 
? 

* Get  proposed  service  number  and  personnel  order. 

order  =  SPACE (20) 

sns  =  SPACE (8) 

(§15,5  SAY  "Edit  for  what  service  number  ; 

"  GET  sns 
READ 

§  17,5  SAY  "Edit  for  what  personnel  order  " 

(§18,7  SAY  "(  or  press  RETURN  to  exit)  "  GET  order 

READ 

* Try  to  find  that  service  number. 

sns  =  LOWER(sns) 
SEEK  sns 
DO  CASE 

•k If  no  service  number  entered,  return  to  ED_AW_PU  menu. 

CASE  sns  =  "  " 

CLEAR 
CASE  order  =  "  " 
CLEAR 

■k If   service  number  found,  try  to  find  that  personnel 

■k order  and  edit  it. 

CASE  FOUND  0 

USE  a_p_mn  INDEX  a  D_mns 
sns  =  sns  +  order 
sns  =  lower(sns) 
SEEK  sns 
IF  FOUND 0 

SET  FORMAT  TO  screenl2 
READ 

SET  FORMAT  TO 
ELSE 

(§5,0  CLEAR 

(§15,5  SAY  order  +  "   Not  found" 
?  CHR(7) 
WAIT 
END  IF 

■k Otherwise , warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND () 
CLEAR 

(?  17,5  SAY  "There  is  no  "  +  sns 
@  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 
ENDDO( Continue  editing  until  user  requests  exit.) 

k Return  to  ED_AW_PU  menu. 

RETURN 

f.  EDEVAL.PRG 

*  Module  name  : EDEVAL.PRG 

*  Author  :KIM,   SAM  NAM 

*  Date  :22  NOV  86 

*  Purpose  :This  is  the  EDIT  module  for  editing  performance 

*  evaluation  records. 

*  It  sets  up  the  edit  performance  evaluation  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 
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*  from  the  called  module,   the  user  is  asked  if  more 

*  inform.acion  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDIT  module. 

*  Called  by      :  EDIT 

^   Modules  called  :  SCREEN71 

*  Variables  used  : 

*  Global  !  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  up  loop  for  editing  performance  evaluation  record. 

USE  p_eval  INDEX  p_eval 
rdate  =  "x" 
sns  —  "x" 

DO  WHILE  sns  #  "  "  .OR.  rdate  tt  "  " 
* Find  out  what  service  number  to  edit. 

CLEAR 

@  2,1  SAY  "EDIT  PERSONAL  PROMOTION  RECORDS" 

@  2,60  SAY  today 

(§2,70  SAY  TIHE() 

(§3,0  SAY  ULINE 

* Qet  proposed  service  number  and  promotion  order. 

rdate  =  SPACE(8) 

sns  =  SPACE (8)  .        ,        ^ 

(§15,5  SAY  "Edit  for  what  service  number  .  ; 

"  GET  sns 
READ 

(§17,5  SAY  "Edit  for  what  rating  date  (e.g >  03/10/86" 

(§18,7  SAY  "  (  or  press  RETURN  to  exit)  "  GET  rdate 

READ 

'^ Try  to  find  that  service  number. 

sns  =  LOWER (sns) 
SEEK  sns 
DO  CASE 

X If   j^Q  service  number  entered,  return  to  EDIT  menu. 

CASE  sns  =  "  " 

CLEAR 

CASE  rdate  =  "  " 

CLEAR 

* If  service  number  found,  try  to  find  that  rating 

■k date  and  edit  it. 

CASE  FOUND  0 

USE  p_eval  INDEX  rating 
sns  =  sns  +  rdate 
sns  =  lower(sns) 
SEEK  sns 
IF  FOUND 0 

SET  FORMAT  TO  screen71 
READ 

SET  FORMAT  TO 
ELSE 

(§5,0  CLEAR 

(§15,5  SAY  rdate  +  "   Not  found" 
?  CHR(7) 
WAIT 
ENDIF 

* Otherwise, warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND 0 
CLEAR 

(§17,5  SAY  "There  is  no  "  +  sns 
@  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 
ENDDO( Continue  editing  until  user  requests  exit.) 

* Return  t(J  EDIT  menu. 

RETURN 
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g.  EDCAREER.PRG 


*  Module  name 

*  Author 

*  Date 

*  Purpose 


EDCAREER . FRG 

KIM,   SAM  NAM 

22  NOV  86 

This  is  the  EDIT  module  for  editing  personal 

*  *         assignment  records. 

*  It  sets  up  the  edit  personal  assignment  record, 

*  accepts  input  from  the  user  and  calls  the 

*  required  modules.  When  control  is  returned 

*  from  the  called  module,   the  user  is  asked  if  more 

*  information  is  required  and  the  process  is  repeated, 

*  or  control  is  passed  back  to  the  EDIT  module. 

*  Called  by      :  EDIT 

*  Modules  called  :  SCREEN81 

*  Variables  used  : 

*  Global  :  i  :  holds  the  value  of  the  user  input. 

*  today:  holds  date 

*  Local   :  none 

*  Set  uo  loop  for  editing  assignment  record. 

USE  careers  INDEX  careers 

order  =  "x" 

sns  ^  " x'* 

DO  WHILE  sns  #  "  "  .OR.  order  #  "  " 

* Find  out  what  service  number  to  edit. 

CLEAR 

(§2,1  SAY  "EDIT  PERSONAL  ASSIGNMENT  RECORDS" 

@  2,60  SAY  today 

@  2,70  SAY  TIME() 

(§  3,0  SAY  ULINE 

7 

■? 

■k Qgt  proposed  service  number  and  personnel  order. 

order  =  SPACE(20) 

sns  =  SPACE(8) 

@  15,5  SAY  "Edit  for  what  service  number  .  ; 

"  GET  sns 
READ 

(§17,5  SAY  "Edit  for  what  personnel  order" 
@  18,10  SAY  "  (  or  press  RETURN  to  exit)    "  GET  order 
READ 

■k Try  to  find  that  service  number. 

sns  =  LOWER(sns) 
SEEK  sns 
DO  CASE 

■k If  j^Q  service  number  entered,  return  to  EDIT  menu. 

CASE  sns  =  "  " 

CLEAR 

CASE  order  =  "  " 

CLEAR 

■k If  service  number  found,  try  to  find  that  personnel 

* order  and  edit  it. 

CASE  FOUND  0 

USE  careers  INDEX  career 
sns  =  sns  +  order 
sns  =  lower(sns) 
SEEK  sns 
IF  FOUND  0 

SET  FORMAT  TO  screenSl 
READ 

SET  FORMAT  TO 
ELSE 

(§5,0  CLEAR 

@  15,5  SAY  order  +  "   Not  found" 

?  CHR(7) 

WAIT 
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ENDIF 

* Otherwise, warn  user  and  allow  another  try. 

CASE  .NOT.  FOUND 0 

@"l7"  5  SAY  "There  is  no  "  +  sns 
d  24,5  SAY  "Press  any  key  to  try  again..." 
WAIT  "  " 
ENDCASE 

ENDDO( Continue  editing  until  user  requests  exit.) 

* Return  to  EDIT  menu. 

RETURN 

7.   DICT.PRG 

"^  MODULE  NAME   :   DICT.PRG 

*  AUTHOR        :   KIM,   SAM  NAM 

*  DATE  :  31  NOV  1986 

*  PURPOSE  :  This  program  allows  the  personnel  officer  to 

*  obtain  information  about  the  data  in  the  database. 

*  CALLED  BY  :   DRIVER 

*  MODULES  CALLED  :   A  problem  developed  as  we  used  the  DRIVER 

*  to  call  subprograms (too  many  files  open). 
^                                             This  program  is  the  main  driver  for  the 

*  dictionary  requests. 

*  VARIABLES  USED: 

*  GLOBAL  :   i  :  holds  the  value  of  the  user  input. 

*  today  :  holds  date 

*  LOCAL      :      none 

*  *  y?  :*r  ^  *  :<:  :*r  X  7*:  X  X  X  T^r  :<t  x  ^  5*:  X  X  7*:  X  7*:  X  7"^  TT  :^  X  TT  7*:  ^  7*;  ;<?  5^  7*c /*r  7>c  7*:  *  :Ar  *  5*:  ^ 

CLEAR 

DO  ^'ffllLE    .T. 

CLEAR 
*=   DO  WHILE  .T.  means  DO  WHILE  TRUE  i.e.  do  forever. 

*  The  DO  WHILE  will  be  terminated  by  an  EXIT  command. 

*  Clear  the  screan  and  display  the  main  menu. 
DO  MENUS CR 

@  2,20  SAY  "DATA  DICTIONARY  INQUIRIES  " 
(§6,36  SAY  "SUBMENU" 
(a  19,33  SAY  "INFORMATION" 

(a  10,9  SAY  "A. What  is  ???  and  how  do  I  enter  it  into  the" 
@  10,53  SAY  "  computer?" 

(§11,9  SAY  "B.What  tyoe  of  information  does  a  particular" 
(?  11,55  SAY  "  file  contain?" 

(§  12,9  SAY  "C.What  file  contains  a  particular  variable?" 
d  13,9  SAY  "D. Dictionary  information." 
@  14,9  SAY  "E. Change  date" 
(|  15,9  SAY  "X.  Exit" 
(§20,3  SAY  "DATE         TIME" 
(§  20,55  SAY  "UPDATED  BY" 
(§21,5  SAY  today 
(?  21,19  SAY  TIMEO 
*@  21,52  SAY  gname 

@  23,10  SAY  "  [  Enter  selection  (  A  -  E,  or  X  to  Exit  )  :  :  ]" 
DO  WHILE  .T. 
i=0 

DO  WHILE  i=0 
i=INKEY() 

(§  21,19  SAY  TIMEO 
(§  23,54  SAY  "" 
IF  UPPER(CHR(i))$"ABCDEX" 

EXIT 
ENDIF 
i=0 
ENDDO 

(?  23,54  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"Ee" 
EXIT 
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END  IF 

SET  COLOR  TO  N/W 
0  19,33  SAY  "INF0PJ1ATI0N" 
@  15,12  SAY  "E.  CHANGE  DATE." 
SET  COLOR  TO  W/N 
(§21,5  GET  today 
READ 

(?  21,5  SAY  today 
(?  19,33  SAY  "INFORMATION" 
(a  15,12  SAY  "E.  CHANGE  DATE." 
(a  23,54  SAY  "  " 
ENDDO 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 
RETURN 
CASE  CHR(i)$"Aa" 

DO  DICTl 
CASE  CHR(i)$"Bb" 

DO  DICT2 
CASE  CHR(i)$"Cc" 

DO  DICT3 
CASE  CHR(i)$"Dd" 
DO  DICT4 
ENDCASE 
ENDDO 

* • when  done,  return  to'fnain  menu 

RETURN 

a.  DIGTl.PRG 

*  MODULE  NAME   :   DICTl. PRG 

*  AUTHOR        :   KIM,   SAM  NAM 

*  DATE  :   30  NOV  86 

*  PURPOSE:   This  module  allows  a  user  to  discover  what  an 

*  element  is,  what  it's  allowable  values  are, 

*  and  how  to  enter  it  into  the  computer. 

*  CALLED  BY  :   DICT.PRG 

*  MODULES  CALLED  :none 

*  VARIABLES  USED: 

*  LOCAL  :  varname,  printout 

*  GLOBAL  :none 

CLEAR  GETS 

CLEAR 

STORE  "  "  TO  varname 

STORE  ".  "  TO  printout 

USE  element 

■k Displays  the  menu  for  making  the  element  name 

* request 

@  2,6  SAY  "This  portion  of  the  data  dictionary; 
inquiries  allows  yo" 

(a  2,61  SAY  "u  to" 

(§3,6  SAY  "ask  questions  about  elements  and  how; 
they  are  entered" 

(§3,61  SAY  "into" 

(§4,6  SAY  "the  computer.   For  example,  you  know  the; 
element  name  of" 

@  5,6  SAY  "somthing  is    SN       ,  but  you  don't  ; 
know  what  it  means" 

(§6,6  SAY  "or  how  to  enter  it.  You  would  type  the; 
element  name  at  the" 

(§7,6  SAY  "Promt  and  would  get  the  full  name   ,; 
allowable  values,  and" 

(§3,6  SAY  "How  to  enter  it." 

(§9,6  SAY  "     If  you're  not  sure  how  to  enter  it," 

(§10,6  SAY  "     enter  what  you  do  know" 

(§  14,10 

ACCEPT  "Please  enter  the  element  name —  "  TO  varname 
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§  20,2  SAY  "Do  you  want  a  printout?  y  OR  n'' 

!?  20,35  GET  printout 

READ 

varname  =  LOWER (varname) 

IF  varname  =  "help-' 

RETURN 
ENDIF 
IF  printout=  "  y" 

SET  PRINT  ON 
ENDIF 

* This  section  displays  all  elements  with  the  required 

* element  name 

DISPLAY  ALL  "Element  ID  ",elementid  for; 
elementid=varname  off 

DISPLAY  ALL  "Full  ID",fullid  FOR  elementid  =  varname  off 
DISPLAY  ALL  "Type  " ,  type  FOR  elementid  =  varname  off 
DISPLAY  ALL  "COMMENTS--''',  comments  FOR  elementid  =; 
varname  off 

SET  PRINT  OFF 
WAIT 
RETURN 

b.  DICT2.PRG 

*  MODULE  NAME   :   DICT2.PRG 

*  AUTHOR        :   KIM,   SAM  NAM 

*  DATE  :   31  NOV  1.986 

*  PURPOSE:   Allows  the  user  to  find  out  how  commonly  used  files 

*  are  structured. 

*  CALLED  BY  :   DICT.PRG 

*  MODULES  CALLED  :  none 

*  VARIABLES  USED: 

*  LOCAL  :   FILENAME,   PRINTOUT 

*  GLOBAL  :  i  :  holds  value  of  user  input. 

*  today:  holds  date 

*  Set  up  loop  for  presenting  menu. 

CLEAR 

DO  WHILE  .T. 

CLEAR 

DO  MENUS CR 

(a  2,14  SAY  "DATA  DICTIONARY  ABOUT  DATA  FILE  STRUCTURE" 

(?  6,34  SAY  "SUBMENU" 

(§  19,33  SAY  "INFORMATION" 

(§  9,5  SAY  "A.  Main  file" 

@  10,5  SAY  "B.  Military  education  file" 

§11,5  SAY  "C.  Personal  education  file" 

(§12,5  SAY  "D.  Rank  file" 

@  13,5  SAY  "E.  Promote  file" 

d  14,5  SAY  "F.  Award  and  punishment  records" 

d  15,5  SAY  "G.  Personal  award  and  punishment" 

(§  16,8  SAY  "  file" 

(a  9,42  SAY  "H.  Award  and  punishment  point  file" 

@  10,42  SAY  "I.  Expert  file" 

(?  11,42  SAY  "J.  Performance  evaluation  file" 

(?  12,42  SAY  "K.  Military  careers  file  " 

(?  13,42  SAY  "L.  File  file" 

(§  14,42  SAY  "M.  User  file" 

@  15,42  SAY  "N.  Change  date" 

@  16,42  SAY  "X.  Return  to  main  menu" 

(?  20,8  SAY  "DATE         TIME" 

@  20,55  SAY  "UPDATED  BY" 

@  21,5  SAY  today 

0  21,19  SAY  TIMEO 

^(?  21,52  SAY  gname 

@  23,10  SAY  "[Enter  selection  (A  -  N,  or  X  to  return  to  main" 

@  23,57  SAY  "  menu)  :  :  ]" 


DO  WHILE  .T. 


166 


i=0 

DO  WHILE  i=0 
i=INKEY() 

@  21,19  SAY  TIMEO 
@  23,65  SAY  "" 
IF  UPPER (CHR(i))$"ABCDEFGHIJKLMNX" 

EXIT 
END  IF 
i=0 
ENDDO 

(§  23,65  SAY  UPPER(CHR(i)) 
IF  .NOT.  CHR(i)$"Nn" 

EXIT 
ENDIF 

SET  COLOR  TO  N/W 
@  19,33  SAY  "INFORMATION" 
(?  15,42  SAY  "N.  CHANGE  DATE" 
SET  COLOR  TO  W/N 
(§21,5  GET  today 
READ 

(§21,5  SAY  today 
(§  19,33  SAY  "INFORMATION" 
(?  15,42  SAY  "N.  Change  date" 
(?  23,65  SAY  "  " 
ENDDO 

STORE  "  "  TO  printout 
CLEAR 

@  15,7  SAY  "Do  you  want  a  print  out?  y  or  n; 
GET  printout 
READ 
IF  printout  =  "v" 

SET  PRINT  ON 
ENDIF 
DO  CASE 

CASE  CHR(i)$  "Xx" 
CLEAR 
RETURN 
CASE  CHR(i)$"Aa" 
USE  main 
LIST  struc 
WAIT 
CASE  CHR(i)$"Bb" 
USE  m_educat 
LIST  struc 
WAIT 
CASE  CHR(i)$"Cc" 
USE  educatmn 
LIST  struc 
WAIT 
CASE  CHR(i)$"Dd" 
USE  rank 
LIST  struc 
WAIT 
CASE  CHR(i)$"Ee" 
USE  promote 
LIST  struc 
WAIT 
CASE  CHR(i)$"Ff" 
USE  awardpun 
LIST  struc 
WAIT 
CASE  CHR(i)$"Gg" 
USE  a_o_mn 
LIST  slruc 
WAIT 
CASE  CHR(i)$"Hh" 
USE  a_p_p 
LIST  struc 
WAIT 
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CASE  CHR(i)$"Ii" 

USE  expert 

LIST  struc 

WAIT 
CASE  CHR(i)$"Jj" 

USE  p_eval 

LIST  struc 

WAIT 
CASE  CHR(i)$"Kk" 

USE  careers 

LIST  struc 

WAIT 
CASE  CHR(i)$"Ll" 

USE  file 

LIST  struc 

WAIT 
CASE  CHR(i)$"Mm" 

USE  user 

LIST  struc 

WAIT 
ENDCASE 
SET  PRINT  OFF 
ENDDO 

* when  done,  return  to  main  menu 

c.  DICT3.PRG 

*  MODULE  NAME   :   DICT3.PRG 

*  AUTHOR        :   KIN,   SAM  NAM 

*  DATE  :   31  NOV  1986 

*  PURPOSE:  Allows  the  user  to  see  what  elements  are  used 

*  in  other  files,  programs,  and  etc. 

*  CALLED  BY  :   DICT.PRG 

*  MODULES  CALLED  :none 

*  VARIABLES  USED: 

*  LOCAL  :  varname,  printout 

*  GLOBAL  :  none 

CLEAR  GETS 

CLEAR 

STORE  "         "  to  varname 

STORE  "  "  to  printout 

USE  contains 

* Displays  the  menu  then  requests  the  variable  name. 

@  2,10  SAY  "This  portion  of  the  data  dictionary  allows  you  to  make" 

(§3,10  SAY  "queries  about  where  certain  pieces  of  information  are" 

(|  4,10  SAY  "used  throughout  system.   For  example,  if  you  wanted" 

@  5,10  SAY  "to  know  where  P_ORDER  was  used  (perhaps  to  assess  th" 

(§5,63  SAY  "e" 

(§6,10  SAY  "possible  imoact  of  transitioning  to  the  15  digit  code)," 

d  7,10  SAY  "you  would  enter  the  variable  name  at  the  prompt  and  tne" 

(?  8,10  SAY  "information  you  would  receive  would  be  listed*  in  the  fo" 

(§8,65  SAY  "rm:" 

@  10,10  SAY  "name  of  the  place  where  used   name  of  the  file , program" 

(B  10,66  SAY  "etc." 

@  11,41  SAY  "Which  uses  it" 

(?  13,10  SAY  "such  as  MAIN    file" 

(?  14,31  SAY  "DRIVER   program" 

(§16,9  SAY  "If  you  don't  know  the  exact  name," 

(§17,9  SAY  "enter  what  you  do  know,  in  all  lower   letters" 

(§  19,9 

ACCEPT  "Please  enter  the  variable  name--  "  TO  varname 

(§22,2  SAY  "Do  you  want  a  printout?  y  or  n" 

(?  22,35  GET  printout 

READ 

IF  varname  =  "helo" 

RETURN 
END  IF 
IF  printout  =  "y" 
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SET  PRINT  ON 
END  IF 

SET  HEADING  OFF 
*---  Displays  all  the  names  and  entity  types  for  the  required 
*---  variable  name. 

DISPLAY  ALL  elname , eitype  FOR  e2name  =  varname  OFF 
USE  process 

DISPLAY  ALL  idl,tvpel  for  id2  =  varname  OFF 
SET  HEADING  ON 
SET  PRINT  OFF 
WAIT 
RETURN 

d.  DICT4.PRG 

*  MODULE  NAME   :   DICT4.PRG 

*  AUTHOR        :   KIM,   SAM  NAM 

*  DATE  :  31  NOV  1986 

*  PURPOSE:   Allows   the  user  to  exit  the   data  dictionary 

*  queries  and  gives  the  more  experienced  user  some  information 

*  on  how  to  use  other  features  of  the  dictionary. 

*  CALLED  BY  :   DICT.PRG 

*  MODULES  CALLED  :  none 

*  VARIABLES  USED: 

*  LOCAL  :  none 

*  GLOBAL  :  none 

CLEAR 

@  1,7  SAY  "Before  you  leave  the  data  dictionary,  you  should  know  t" 

(§1,62  SAY  "hat  other" 

(§2,7  SAY  "questions  can  be  answered  about  this  SYSTEM  database" 

(§2,60  SAY  "^system" 

d  3,7  SAY  "using  the  DBMS  III+  query  language.   The  previous  querie" 

@  3,63  SAY  "s  were" 

@  4,7  SAY  "designed  to  answer  typical  questions  a  primary  user  of" 

@  4,62  SAY  "the  system" 

(§5,7  SAY  "might  have  while  using  the  system.  For  the  individual  w" 

(§5,62  SAY  "ith  a" 

(§6,7  SAY  "knowledge  of  DBMS  III+,  information  exists  about" 

(§8,7  SAY  "SYSTEM--  The  PERSONNEL  MANAGEMENT  SYSTEM" 

(§9,7  SAY  "PROGRAM--  Programs  used  in  the  PPERSONNEL  MANAGEMENT  SYSTEM" 

@  10,7  SAY  "CONTAINS--   Information  about  where  entities  are  contai" 

(§  10,62  SAY  "ned" 

(§  11,19  SAY  "in  other  entities" 

(I  12,7  SAY  "PROCESSES--   Information  about  where  entities  act  upon" 

(§  12,62  SAY  "another  entity." 

(I  13,7  SAY  "ELEMENT--  Descriptions  of  the  instances  of  data  such  as" 

(§  13,63  SAY  "service" 

(§  14,19  SAY  "number" 

(§15,7  SAY  "FILE--   Describes  the  files  used  in  this  system  " 

(I  16,7  SAY  "USER--  Describes  users  of  in  this  system." 

WAIT 

RETURN 
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APPENDIX  C 
DATA  DUMP 


.  use  (nam 

.  list  struc 

Structure  -for-  dataDase:  C:main.db  + 

Number  o-f  data  records;         & 

Date  o-f  last  uodate    :  01/31/B7 

Field   Field  Name   Type        Width 


Dec 


1 

SN 

Character 

8 

2 

NAME 

Character 

25 

3 

ORG_BRANCH 

Character 

20 

4 

C_TVPE 

Character 

10 

5 

BaRN_DATE 

Character 

a 

b 

eORN_PLACE 

Character 

15 

»«  Total  «« 

37 

.  1  ist 

Record*   3N 

NAME 

ORG_BRANCH 

_DATE 

90RN_FLACE 

1   21554 

kiin.sam  nam 

in-f  antry 

1/54 

chunnam  do 

2   23456 

park.jae  bock 

in-f  antry 

1/56 

Seoul  city 

3   22222 

kanq, seon  mo 

enigineer 

1/56 

Seoul  city 

4   2000 1 

jung.jee  ho 

in+antry 

1/53 

pusdn  city 

5   550673 

joo,dae  joon 

in-f  antry 

1/53   kyoungnam  do 
6   23345 


C_TYFE  "  BORN 
K.M,A#33  07/2 
K.M.A#35  OB/2 
K.M.A#35  'J9/2 
K.M.A«33  06/2 
3K.M.A«13   06/2 


.  use  m_educat 

.  list  struc 

Structure  for    database:  C:  m_educat .  db-f 

Number  of    data  records:  6 

Date  o-f  last  update    :  12/02/B6 

Field   Field  Name   Type  Width 

1  CNAME        Character  20 

2  CLASS_SIZE   Numeric  4 

3  START_DATE   Character  8 

4  END_DATE     Character  9 

5  SNAME        Character  30 

6  CLASS_MEAN   Numeric  5 
««  Total  ««  ~  76 


Dec 


.  list 
Record*   CNAME 

CLASS_MEAN 

1  in+antry  o.b-c*»5 
80.05 

2  engineer  o.b.ctt3 
79.50 

3  in-fantry  o.a.c»234 
82.50 

4  engineer  o.a.c«35 
80 .  05 

5  in-fantry  o.b.ctt? 
85.60 

6  engineer  o.a.cttl 
78.50 


CLASS_SIZE  START_DATE  END_DATE  SNAME 

200  04/01/77  07/01/77  army  in-fantr-/  schoo 

35  04/01/79  07/01/79  army  engine>er  schoo 

155  06/01/82  11/20/82  army  infantry  schoo 

68  07/21/84  12/01/84  army  engineer  schoo 

200  04/01/79  07/01/79  army  in-fantry  =choo 

45  04/01/77  07/01/77  army  engineer  schoo 
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Data  o-f 

last  updat*    1  12/18/'a6 

Fi»ld  f 

1  el d  Name 

Type 

Width 

Dec 

I       SN 

Character       8 

2   CNAME 

Character      20 

3   E 

.GRADE 

Character      15 

4   MEAN 

renter  i  c 

3 

2 

>t  Total 

It 

49 

.  1 1  «t 

R«cord« 

SN 

CNAME 

E.GRADE 

1 

21554 

infantry 

o.b.c<»5 

outstanding 

2 

21554 

i  n-f  antry 

o.a.c«234 

outstanai ng 

3 

23456 

in+antry 

o.a.c»7 

outstandi ng 

4 

23456 

xn-f  antry 

o.a.c«234 

outstandi ng 

3 

engi neer 

o. 0.c*Z 

middle 

6 

engineer 

Q.a.ct»35 

outstanding 

7 

20001 

engineer 

o.b.cWl 

outstanding 

8 

20001 

engineer 

o.a.cl»35 

outstiindi  ng 

9 

550673 

I n+antry 

o.a.ct»234 

outstandi ng 

10 

21554 

army  coiledge*25 

outstanding 

MEAN 
93.30 
93.50 
''2.50 
''I.  SO 
85.50 
93.50 
95.40 
93.  SO 
91.50 
93.50 


.  use  rank 

.  list  struc 

Structure  tor    database!  Cirank.db* 

Number  o*  data  records:        13 

Date  a*    last  update    :  01/09/37 


Field  f 

leld  Name 

Type 

Width 

Di 

1   RANKS 

Character 

20 

2   P 

ORDER 

Character 

20 

3   TDATE 

Character 

3 

««  Total 

(t 

49 

.  list 

Record* 

RANKS 

P.QRDER 

I 

2nd  lieutenant 

77-33 

army 

2 

2nd  lieutenant 

76-13 

army 

3 

1st  lieutenant 

77-13 

army 

4 

1st  lieutenant 

79-33 

army 

3 

2nd  lieutenant 

79-35 

army 

6 

captain 

79-13 

army 

7 

1st  lieutenant 

90-35 

army 

a 

captain 

30-33 

army 

9 

catain 

82-35 

army 

10 

major 

94-33 

army 

11 

major 

96-13 

army 

12 

major 

36-35 

army 

13 

1st  lieutient 

B5-100  arm' 

TDATE 

03/23/77 

10/01/76 

10/01/77 

04/01/77 

03/23/79 

10/01/79 

04/01/80 

04/01/80 

04/01/82 

12/01/84 

06/01/86 

10/01/36 

04/01/83 


.  use  promote 

.  1 ist  struc 

Structure  -for  databases  C:  promote,  db'f 

Numoer  o4  data  recorost        20 

Date  o*  last  update    i  12/18/86 

Field   Field  Name   'ype        Width 

1  SN  Character  3 

2  P_ORDER  Character  20 
«8    Total "««  29 


Dec 


.  list 

Record* 

SN 

P_ORDER 

1 

21554 

77-33 

army 

2 

21554 

79-33 

army 

^ 

21554 

90-33 

army 

4 

21554 

94-33 

army 

3 

23456 

79-35 

army 

6 

23456 

90-35 

army 

7 

23456 

32-35 

army 

a 

23456 

86-:.5 

army 

9 

79-35 

army 

10 

8U-35 

army 

11 

92-35 

army 

12 

86-35 

army 

13 

2000 1 

77-33 

army 

14 

20001 

79-33 

army 

15 

20O(J  I 

90-33 

army 

16 

200O1 

94-33 

army 

17 

550673 

76-13 

army 

18 

550673 

^7-13 

army 

19 

550673 

79-13 

army 

20 

550673 

86-13 

army 
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.     u^e    aMar  apaii 

.     list    struc 

Structure  ♦or  data&asa:  C :  awar Coun.  db'f 

Number  o*  data  records:        5 

Date  of  last  update    :  12/18/36 

Field   Field  Name   Type        Width     Dec 


1   KIND 

Character 

30 

2   P  ORDER 

Character 

20 

3   TDftTE 

Character 

3 

*t    Total  »« 

59 

.  list 

Record* 

3N 

1 

21554 

2 

21534 

z 

21554 

4 

23456 

5 

23456 

6 

22222 

7 

20001 

.  list 

Record*  KIND  P_ORDER  TDATE 

1  staff  of  chief  awarding  77-100  army  0''/21/T7 

2  armv  commander  awarding  92-100  3rd  amy  09 '21/92 

3  corps  commander  awarding  85—300  6th  corps  05/07/95 

4  division  commander  awarding     93-300  5th  division   07/21/83 

5  staff  of  chief  award  77-100  army  09/21/77 


.  use  a_p_mn 

.  1  I  St  struc 

Structure  for  dataoase:  C!a_p_mn.dbf 

Numoer  of  aata  records:        8 

Date  of  last  update    i  12/19/96 

Field   Field  Name   Type        Midth     Dec 

1  SN  Ct^ar^cter  8 

2  P_QRDER      Character      20 
f«  Total  ««  29 


P .ORDER 

77-100  army 

92-100  3rd  army 

85-300  6th  corps 

82-100  3rd  army 

83-300  5th  division 

85-30O  6th  corps 

92-100  3rd  army 

OOOl.     35-300  6th  corps 


•  use  »_P^P 

.     list  struc 

Structure  for  databases  C:a_p_p.dbf 

Numoer  of  aata  recordsj       13 

Date  of  last  update    «  11/27/86 

Field   Field  Name   Type        Midth     Dec 

1  KINO         Character      30 

2  POINT        Numeric  4        I 
tt  Total  t«                        35 

.  list 

Record*  KIND  POINT 

1  regimental  commander  awarding  0.3 

2  brigade  commander  awarding  1.0 

3  division  commanaer  awarding  1.0 

4  corps  commander  awarding  1.2 

5  army  commander  awarding  l.S 

6  chief  of  staff  awarding  2.0 

7  minister  of  de+ence  awarding  2.S 

8  prime  minister  awarding  3.0 

9  president  awarding  S.O 

10  decoration  S.O 

11  light  disciplinary  -1.0 

12  heavy  disciplinary  —3.0 

13  military  trial  -5.0 


.  use  95<oert 

.  list  struc 

Structure  for  database:  C; expert . dbf 

Number  of  data  records:         3 

Date  of  last  update    ;  12/18/86 

Field   Field  Name   Tvpe        Width     Dec 

1  3N  Character        g 

2  EXFERTITLE   Character      20 
*«  Total  »«  29 
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.  its'. 

R»cord#   SN       E XPERT !TLE 
I   21554     c.p.a 


4  21554     c.p.a 

5  21554    c.p.a 


c.p.a 

civil  engineer 


use  p_eval 

list  struc 


Structure  +or  database;  C:p_eval.db+ 

NumOer  o-f  data  records:         4 

Date  o^  last  update    t  12/18/86 

Field   Field  Name 

Type        Width 

1   SN 

Character       8 

2   GRADE 

Character       2 

3   RATINGDATE 

Character       3 

«»  Total  t« 

19 

.  list 

Record*   SN 

GRADE  RATINGDATE 

1   21554 

aa     03/10/78 

2   21554 

aa     03/10/79 

3   21554 

ab     03/10/80 

4   21554 

ba     03/10/81 

Dec 


.  use  career 

.  list  struc 

Structure  for  database:  C:career.dbf 

Number  a*  data  recordsi  8 

Date  o+  last  update    :  01/31/87 

Field   Field  Name  Type        Width     Dec 

1  SN  Character       8 

2  START_DATE  Character       9 

3  END_DATE  Character       8  • 

4  SE_NO  Character       7 
3   P_aRDER  Character      20 

««  Total~««  52 

.  list 

Record*   SN  START_DATE  END_DATE  SE_NO    P_aRDER 

1  21554  07/08/77    07/08/78  llTlOOl  77-101  55th  division 

2  21554  07/09/78    09/09/79  1111001  78-101  55th  division 

3  21554  09/10/79    05/21/82  1111001  79-101  55th  division 

4  23456  07/08/79    07/08/82  3333001  79-101  33rd  division 

5  23456  07/09/81  07/09/84,3333001  81-101  33rd  division 
6-  23456  07/1O/84  3333001  84-101  33rd  division 
7  22222  07/08/79  07/08/81  llllOOO  79-101  55th  division 
B   22222  07/09/81    07/10/84  1111001  84-101  55th  division 


.  use  unit 

.  1 1st  struc 

Structure  for  database:  C:unit.db-f 

Number  o*  data  records:        8 

Date  of  last  update    :  01/31/87 

Field   Field  Name   Type        Width     Dec 

1  SE_NO        Character       7 

2  DUTY_TITLE   Character      20 

3  UNIT         Character      23 
««  Total  ««  53 

.  list 

Record*  SE.NG  DUTY_TITLE  UNIT 

1  1111001  platoon  leader  55s;  227r  2bn  5co  2pl 

2  1111001  s-3  air  55x  227r  2bn 

3  1111001  company  commander  55y,  227r  Ico 

4  3333001  platoon  leader  33>!  456r  2bn  lOco  Ipl 
3  3333001  comoany  commander  33x  45far  2bn  Ico 

6  3333001  battalion  3-3         33x  456r  Zbn 

7  1111000  platoon  leader        55>:  egineer  bn  3co  Ipl 

8  1111001  company  commander     55x  engineer  bn  3co 
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APPENDIX  D 
QUERY  SAMPLE 

Service  number  :  21554 

Personnel  order  or  promotion  order  :  86-100  army 

Course  name  :  infantr>'  o.a.c#234 

Promotion  year  :  85 

Rank  :  major 

Expert  title   r  c.p.a 

Award  and  punishment  name  :  army  commander  awarding 

Evaluation  date   :  03/10/85 
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